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PREFACE 


This  report  describes  progress  under  this  contract  during  the 
period  trom  1 July  1975  to  31  December  1975. 

Under  tne  terms  of  this  contract,  Honeywell  Information  Systems, 
Inc.  is  providing  the  technical  integration  of  the  tasks 
necessary  to  begin  the  design,  development,  and  certification  of 
a secure  Multics  system.  Honeywell  has  subcontracted  some  of 
these  tasKs  with  Massachusetts  Institute  of  Technology  (MIT)  and 
Stanford  Research  Institute  (SRI) . 

During  this  reporting  period,  these  tasks  included: 

1.  The  reduction  in  the  size  and  complexity  of  the 
software-related  functions  of  tne  Multics  system. 

2.  The  design  and  development  of  a Secure  Front-End 
Processor  (SEEP)  which  is  based  upon  a securable 
minicomputer  architecture. 

3.  The  development  of  specifications  for  a security  kernel 
for  Multics  and  the  SEEP. 

4.  The  analysis  of  the  characteristics  of  a secure  Multics 
system . 

5.  An  investigation  and  development  of  a certif ication 
approach  for  the  Multics  and  SFEP  kernels. 

M IT  performed  Task  1 above  and  SRI  performed  Task  5 above  durina 
tnxs  reporting  period  as  subcontractors  with  Honeywell. 

Tne  reader  is  assumed  to  be  familiar  with  the  Multics  system  and 
also  tne  proolem  of  computer  security.  Related  terms  sucn  as 
"Trojan  horse",  "Reference  Monitor",  etc.  are  not  defined  in  tnis 
document . 
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SECURITY  KERNEL  EVALUATION  FOR  MULTICS 
AND  SECURE  MULTICS  DESIGN,  DEVELOPMENT 
AND  CERTIFICATION 


I.C  INTRODUCTION 

The  problem  of  security  in  computer  systems  has  been  under  study 
for  several  years.  The  Air  Force  has  sponsored  several  studies 
and  development  projects  aimed  at  improving  understanding  of 
security  in  computer  systems,  developing  a sound  theoretical 
basis  for  further  work,  and  demonstrating  accomplishments  in  the 
field.  Many  of  these  projects  have  been  associated  with  the 
Multics  system. 

The  overall  goal  of  these  efforts  nas  been  to  develop  a 
certifiaoly  secure  computer  system  for  general  use  by  the 
military  to  meet  their  operational  requirements.  This  report 
describes  progress  under  this  contract  during  the  period  from  1 
July  1975  to  31  December  1975  as  part  of  a lona-term  plan  to  take 
the  Multics  system  from  its  present  form  to  a prototype  secure 
Multics  system  which  can  be  used  to  demonstrate  the  feasibility 
of  software  certification.  Tnree  activities  are  being  conducted 
in  parallel  to  implement  this  plan.  The  first  parallel  effort  is 
tne  design  of  a Multics  security  kernel  and  the  simplification  of 
tne  Multics  operating  system.  The  second  parallel  effort  is  tne 
development  of  a Secure  Front-End  Processor  (SFEP)  for 
integration  and  certification.  The  third  parallel  effort  is  the 
development  of  a technology  and  a set  of  tools  which  allow 
eventual  certification  of  the  Multics  and  SFEP  software  kernels. 


1.1  Lack around 

ine  military  faces  an  increasing  need  for  operational  computer 
systems  capable  of  processing  several  levels  of  classified 
information  at  the  same  time.  Present  systems  are  unable  to 
support  secure  multilevel  processing  due  to  fundamental 
weaknesses  in  their  basic  design,  since  security  was  not  a 
concern  when  they  were  developed.  The  weakness  is  that  current 
hardware/software  systems  are  unable  to  adequately  protect  the 
information  that  they  process. 

Currently,  the  military  meets  the  need  for  processing  several 
levels  of  information  by  one  of  two  methods.  Either  all  security 
levels  are  processed  together  at  the  level  of  the  nighest 

classification  present,  or  each  level  is  processed  by  itself. 
Eoth  methods  have  Deen  less  than  satisfactory.  Tne  problem  with 
processing  all  levels  together  is  that  all  users  and  all 
equipment,  including  terminals  and  communications  facilities, 
must  be  clearec  to  the  highest  classification  tnat  the  system  can 
ever  process.  The  proolem  with  separate  processing  is  that  a 
separate  computer  system  or  a separate  period  of  time  is  required 


for  each  level  handled, 
different  clearance  levels 
costly  and  inefficient, 
handling  of  information 
levels  of  clearance. 


Also,  sharing  of  data  between  users  of 
cannot  be  permitted.  Either  method  is 
Neither  method  allows  simultaneous 
at  several  levels  for  users  of  several 


Multics  is  the  most  advanced  general  utility  system  as  far  as 
security  is  concerned.  Security  was  one  of  the  initial  design 
goals  of  tne  Multics  system  designers  and  has  been  a major 
concern  of  the  designers  and  developers  throughout  the  history  of 
tne  system.  Even  with  this  concern  for  security,  the  present 
Multics  system  cannot  be  certified  secure.  Multics,  however, 
does  present  the  best  available  base  upon  wnich  to  build  a 
certifiably  secure  multilevel  computer  utility. 

Secure  communications  has  also  presented  operational  problems  to 
the  military.  A secure  on-line  system  requires  a secure 
communications  network.  while  the  techniques  of  securing 
communications  lines  and  terminals  have  been  well  developed,  a 
certifiably  secure  communications  processor  is  still  undeveloped. 
A secure  multilevel  system  must  have  a compatible  and  secure 
Front-End  Communications  Processor  to  be  able  to  properly  handle 
multiple  levels  of  classified  inf orm.ation . Thus  tne  Secure 
Front-End  Processor  is  essential  to  the  development  of  a secure 
Mul tics . 

Eoth  economic  and  operational  considerations  make  development  of 
a certifiably  secure  multilevel  system  desirable.  Recent 
advances  in  computer  technology  indicate  tnat  it  should  be 
possible  to  produce  a system  that  can  process  an  arbitrary  mix  of' 
classified  and  unclassified  information  simultaneously  on  a 
single  computer  system.  The  system  should  serve  both  cleared  and 
uncleared  users  and  snould  rely  on  tne  computer  system's  internal 
nardware/sof tware  controls  to  enforce  security  and  nsed-to-<now 
requirements.  Of  orimary  importance  is  that  tne  system  be 
certifiaoly  secure.  Tnat  is,  it  must  be  possible  to  prove  that 
the  system  is  complete  and  witnout  flaw  in  any  of  its 
security-related  aspects. 

The  Air  Force  has  been  working  on  the  problem  of  providing  a. 
certifiably  secure  multilevel  system  for  several  years.  In  1970, 
tne  Air  Force  Data  Services  Center  ( AFDSC)  requested  tne 
Electronic  Systems  Division  (ESD)  to  support  development  of  an 
open  multilevel  system  for  the  AFDSC  Honeywell  635  systems.  The 
resulting  studies  pointed  out  the  severity  of  tne  problem  and  led 
to  the  formation  of  a computer  security  technology  planning  study 
panel.  The  panel's  report  (1)  described  the  fundamental  problems 
and  delineated  a program  to  develop  the  desired  system.  The 
panel  recommended  that  the  technical  approach  to  the  proolem  be 
"to  start  with  a statement  of  an  ideal  system,  a model,  and  to 
refine  and  move  tne  statement  tnrouoh  various  levels  of  design 
into  the  mechanism  that  implement  the  model  system". 
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The  basic  component  of  the  ideal  system  was  also  identified  by 
this  panel.  This  component  is  known  as  the  Reference  Monitor,  an 
abstract  mecnanism  that  controls  access  of  subjects  (active 
system  elements)  to  objects  (units  of  information)  within  the 
computer  system  and  enforces  the  rules  of  the  military  security 
system  on  such  access.  Three  requirements  were  recognized  for  a 
Reference  Monitor: 

i 

a.  Complete  Mediation  - the  mechanism  must  mediate  every 
access  of  a subject  to  an  object. 

b.  Isolation  - the  mechanism  and  its  data  bases  must  be 
protected  from  unauthorized  alteration. 

c.  Verifiability  - the  mechanism  must  be  small,  simple,  and 
understandable  so  that  it  car.  be  completely  tested  and 
verified  (certified)  to  perform  its  functions  correctly. 

The  mechanism  that  implements  the  Reference  Monitor  in  a 
particular  computer  system  nas  been  termed  the  security  kernel. 
Much  subsequent  work  nas  been  devoted  to  identifying  the 

cnaracteristics  of  a security  kernel  and  to  exploring  the 
technology  involved  in  producing  a security  kernel  for  some 
computer  system. 

LSD  initiated  development  of  formal  mathematical  models  of  tne 
ideal  Reference  Monitor  in  1972.  This  work  (2,  3)  resulted  in  a 
model  of  a secure  computer  system  as  a finite-state  mechanism 
tnat  makes  explicit  transitions  from  one  secure  state  to  another. 
The  rules  of  the  model  formally  define  the  conditions  under  which 
a transition  from  state  to  state  can  occur.  The  rules  have  beer, 
proven  to  allow  only  transitions  tnat  preserve  tne  security  of 
information  in  tne  system.  The  model  specifies  requirements  for 
tne  operation  of  a security  kernel.  These  requirements  were  ta^en 
directly  from  tne  Defense  Department  regulations  on  handling 
sensitive  information  (DoD  Directive  5200. 1-R) . with  tne 
availability  of  the  model,  the  problem  of  validation  is  now 
reduced  to  providing  complete  assurance  that  a particular 
security  kernel  behaves  exactly  as  tne  model  requires. 

work  on  the  technology  of  certification  progressed  in  parallel 
with  the  work  on  the  model.  In  1973,  Price  (4)  identified  a 
methodology  for  verification  of  a kernel.  More  detailed 
developments  of  this  validation  methodology  nave  been  reported  by 
MITRE  (5,  6).  Another  approach  has  oeen  explored  which  may  be 

more  suitaole  to  large  software  modules  (7). 

Other  activities  nave  oeen  devoted  to  the  problem  of  building  a 
security  kernel  for  a practical  system  (8,  9).  This  'work  has 
demonstrated  the  soundness  of  the  basic  concepts  and  also  pointed 
out  some  of  the  problems  that  lie  in  the  way  of  realizing  a 
security  Kernel  on  a large  system.  This  worn  has  been  the  basis 
for  development  of  a secure  communications  processor  which  is  an 


integral  component  of  the  long-range  goals  of  this  program. 

A major  project  in  the  development  process  is  the  development  of 
a security  kernel  for  a large  resource  sharing  system.  The 
system  cnosen  for  tnis  effort  is  Multics.  There  are  two  reasons 
that  this  choice  was  made.  First,  the  hardware  base  of  the 
Multics  system,  the  Honeywell  68/80  computer,  fias  been  identified 
as  best  suited  of  all  off-the-shelf  large  computer  systems  for 
the  support  of  a security  kernel  (10).  Second,  the  Multics 
system  arcnitecture  was  conceived  and  developed  with  security 
requirements  specifically  in  mind. 

One  project,  now  completed,  involved  the  design  and  production  of 
a Multics  system  capable  of  supporting  a two-level  (Secret  and 
Top  Secret)  environment  for  the  Air  Force  Data  Services  Center 
(11,12).  This  system  implements  security  controls  based  on'  the 
military  access  rules,  but  it  does  not  completely  handle  tne 
threat  of  a hostile  penetration.  From  these  efforts,  additional 
insiqnt  was  gained  in  the  problems  of  designing  and  developing  a 
security  kernel  for  Multics. 


1.2  Summary  of  tnis  Progress  Report 

Design  of  a security  kernel  for  Multics  was  started  as  a joint 
effort  oetween  personnel  from  £SD,  the  MITRE  Corporation,  tne 
Massachusetts  Institute  of  Technology,  and  Honeywell  Information 
Systems.  This  design  effort  has  led  to  a more  complete 
understanding  of  the  general  problem  and  has  provided  the 
foundation  for  a development  plan  wnich  Honeywell  submitted  to 
tne  Air  Force  durinc  this  reporting  period  ("Multics  Security 
Integration  Requirements,  1 January  1976  - 31  December  19oC"  as 
CD.vL  Item  A 006  of  31  October  1975)  . 

v.or.<  is  progressing  on  formal  specifications  for  the  Multics 
security  Kerne!.  (13)  and  on  simplification  and  reorganization  of 
tne  Multics  operating  system.  Based  on  these  efforts,  tnis 
report  aescrioes  the  beginning  of  a major  project  to  refine  the 
current  Multics  system  and  reimplement  critical  portions  of  tne 
system  to  produce  a certifiable  kernel  which  will  interface  witn 
a certifiable  front-end  communications  processor  w'ith  its  own 
security  Kernel.  Tne  result  will  be  a prototype  Multics  system 
which  may  meet  the  goal  of  Air  Force  certification. 

The  long-range  goals  of  tnis  project  can  be  described  in  terms 
of  three  major  development  phases:  development  of  a tecnnoloqy 
to  support  the  development  of  a certifiable  system,  development 
of  nardware  and  software  for  a prototype  Secure  Eront-Enu 
Processor,  and  development  of  a certifiable  orototype  Multics 
system  with  a security  kernel  interfacing  witn  the  Secure 
Front-End  Processor. 


Due  to  the  complexity  involved,  these  three  development  pnases 
have  been  furtner  broken  down  into  five  distinct  and  parallel 
activities  for  this  performance  period  as  follows: 

1.  Research  into  the  Reduction  of  the  Present  Mul tics 
supervisor . 

2.  Secure  hultics  Specification  Preparation 

3.  Secure  Front  End  Processor  Hardware  Development 

4.  Secure  Communications  Oriented  Processor  Software 

Development 

5.  Certification  Planning 

This  report  describes  the  progress  of  these  activities  during 
tnis  reporting  period.  Appendix  A describes  a hardware 

development  program  to  ruggedize  a Level  6 minicomputer  for  use 
as  the  SFEP.  This  report  then  continues  with  Appendix  B oy 
identifying  the  documentation  which  has  been  prepared  for  the  Air 
Force  auring  this  six-month  period.  Finally,  this  report 
concludes  witn  a bibliography. 


2.0.  MULTICS  SUPLRVISGR  RLDUCTION 


Tnis  researcn  onase  of  tne  proqram  is  being  performed  oy 

massacnusetts  Institute  of  Technology's  Project  MAC  Computer 
Systems  Research  Division  as  a suocontractor  to  Honeywell.  The 
specific  goals  of  tnis  continuing  research  effort  are  to  identify 
tne  minimum  mechanism  that  must  be  correct  to  guarantee  computer 
enforcement  of  desired  constraints  on  information  access,  to 
simplify  tne  structure  of  that  minimal  mechanism  to  make 
certification  possible,  and  to  demonstrate  by  test  implementation 
tnat  tne  security  kernel  so  developed  is  capable  of  supporting 
all  the  functions  of  the  Mul tics  system.  Because  Mul tics  permits 
the  direct  sharing  of  information  among  simultaneous 

computations,  this  research  can  lead  to  a better  understanding  of 
tne  structures  necessary  to  support  tne  primary  Kultics  functions 
and,  therefore,  leads  to  a Multics  system  wnose  security 
features  inspire  a high  degree  of  confidence. 

At  the  conclusion  of  tnis  repotting  period,  tnis  research  project 
has  run  for  aoout  two  and  a naif  years  of  its  intended  tour  year 
span.  So  far,  tne  reductions  in  size  and  the  simplification  in 
structure  of  tne  security-sensitive  software  in  Multics  tnat  were 
expected  to  result  from  tne  early  tasks  is  showing  significant 
progress.  As  the  results  from  these  initial  tasks  are  becoming 
available,  'anc,  indeed,  being  assimilated  into  the  readily 
availaole  version  of  multics,  furtner  detailed  researcn  is 
emerging  and  being  contemplated  from  tne  experience  gained  in 
the  early  work.  Specifically,  during  tnis  reporting  period,  a 
comprehensive  study  of  tne  Multics  Storage  system  was  undertaken 
by  many  project,  participants. 

2 . i Task  Summary 

me  following  is  a summary  of  tne  status  of  tne  various  tas<:s  in 
this  research  activity. 

Prior  to  this  reporting  period,  the  following  tasks  were 
completed  : 

Removal  of  the  Dynamic  Linker  from  Ring  Zero 
Removal  of  Name  Space  Management  from  Ring  Zero 
Development  of  Fast  Processes  in  Ring  Zero 
hian  Level  Description  of  System  Functionality 
Study  of  Removal  of  User  I/C  from  Ring  Zero 

During  this  reporting  period,  the  following  research  task  was 
comp ie  ted : 

Formulation  of  Criteria  to  Include  Modules  within  the  Kernel 
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>vitnin  this  activity,  the  following  research  taSKs  are 
continuing : 

Page  Control  Restructure 

Traffic  Control  Restructure 

Answering  Service  Restructure 

System  Initialization  Restructure 

Multitasking  in  the  User  Ring  v 

Methodology  of  Designing  a Certified  Computer  System 

Study  of  Multics  Security  Holes 

Restructure  of  the  Network  Control  Program 

New  Buffer  Strategy  for  Input/Output 

Study  of  Relationship  between  Reliability  and  Security 

Study  of  the  Storage  Hierarchy 

Support  of  User-Defined  Object  Types 

Multics  Performance  benchmark 

Independent  Domains  and  Ereakproof  Services 


'2 . 2 Completed  Tasks 

The  tasks  listed  below  have  been  completed  oy  the  Computer 
Systems  Research  Division  of  Project  MAC  at  MIT. 

1.  Removal  of  the  Linker  from  Ring  0 

This  task  was  an  important  first  step  in  pruning  unnecessary 
programs  from  the  portion  of  the  system  which  must  be  certified. 
Several  other  components  of  the  system,  in  particular  the 

management  of  reference  names,  can  be  removed  from  the  kernel 
after  the  linker  has  been  removed.  Final  documentation  of  this 
tas*  nas  appeared  in  the  form  of  a Project  MAC  Technical  Resort 
and  a formally  presented  technical  paper  (15,  1G)  . 

The  initial  version  of  the  user  ring  linker  showed  7 to  1C 
percent  slower  performance  than  tne  standard  system.  This  was 

improved  to  performance  equal  to  tne  standard  system.  The  user 

ring  linger  will  be  installed  in  tne  standard  system  as  part  of  a 
mechanism  to  prelink  the  system  libraries.  This  prelinking 

eliminates  a special  case  in  the  user  ring  linker,  making  it  even 
less  complex.  This  task  is  now  essentially  complete. as  far  as 
Project  hAC's  Computer  Systems  Research  Division  is  concerned. 
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2.  Removal  of  Name  Space  Management  from  Ring  0 

This  task  removed  from  the  supervisor  the  facilities  for  managing 
the  association  between  reference  names  and  segments  in  the 
address  space  of  a process.  The  association  between  names  and 
segment  numbers  is  now  maintained  in  tne  user  ring  rather  than  in 
ring  0,  leaving  in  the  supervisor  only  the  association  between 
segment  numbers  and  unique  identifier. 

Removing  the  reference  name  management  mechanism  from  the 
supervisor  required  that  a data  base  central  to  the  management  of 
the  address  space  of  a process  - the  Known  Segment  Table  or  KST  - 
be  split  into  a private  and  a common  part,  and  that  the 
supervisor  learn  to  lie  convincingly  on  occasion  about  the 
existence  of  certain  file  system  directories.  The  result  of  the 
removal  is  a reduction  by  a factor  of  five  in  the  size  of  tne 
protected  code  needed  to  manage  the  address  soace  of  a process. 
Another  result  is  a new  simpler  interface  to  the  file  system 
portion  of  the  supervisor.  Instead  of  identifying  a directory 
witn  a character  string  tree  name,  a segment  number  is  now  used. 
Tne  algorithm  for  following  a tree  name  through  the  directory 
Hierarchy  to  locate  the  named  element  is  thus  removed  from  the 
supervisor.  Performance  tests  indicate  that  the  new  desian 
outperforms  the  old. 

The  task  has  been  described  in  a Froject  MAC  Tecnnical 'Report 
(17).  The  mechanism  has  been  combined  witn  the  user  ring  linker 
and  will  be  installed  in  the  standard  system  as  a unit.  This 
tasx  is  now  completed  as  far  as  the  MAC  Computer  Systems  Research 
Division  is  concerned. 


3.  fast  Processes  in  Ring  C 

One  approach  to  understanding  and  simplifying  the  structure  of 
ring  0 is  to  separate  portions  of  tne  supervisor  into  separate 
processes.  It  is  necessary  that  tnere  oe  available  a class  cf 
process  wnich  is  very  inexpensive  to  run  so  that  tne  separation 
could  be  accom.pl  ished . This  task  nas  involved  the  design  and 
implementation  of  such  fast  processes.  A special  kind  of  process 
has  been  developed  which  runs  only  in  ring  0,  wnich  nas  limited 
capability,  and  is  very  efficient  to  execute. 

The  fast  process  .is  one  which  makes  very  restricted  demands  cn 
its  environment.  The  process  has  a leaitimate  stack,  can  abandon 
tne  orccessor  by  means  of  the  wait  and  notify  mechanism,  and  can 
taxe  page  faults,  but  is  restricted  from  taking  segment  faults  or 
adding  segments  to  its  address  space.  Tne  wired  storage  required 
for  these  processes  has  been  reduced  by  two  strategies.  First, 
tnere  is  one  descriptor  segment  per  processor,  usea  by  any  of 
tnese  fast  processes  wnen  it  runs.  Second,  tne  Process 
Descriptor  Segment  (PUS)  nas  been  split  into  two  components,  only 
one  of  which  is  needed  for  these  processes.  Approximately 
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one-fourth  of  a page  of  storage  is  required  for  these  processes 
with  the  rest  of  the  page  available  for  the  process  stack.  Thus 
if  a fast  process  requires  less  than  three-quarters  of  a page  of 
stack,  there  is  only  one  page  required  in  core  when  tnat  process 
runs . 

Fast  processes  were  tested  in  use  by  rewriting  the  interrupt  side 
of  the  typewriter  device  interface  module  so  that  it  ran  as  one 
of  these  processes  rather  than  directly  as  a result  of  an 
interrupt.  Nine  pages  were  aole  to  be  unwirec  as  a result  of 
this  change.  An  initial  version  of  this  typewriter  manager 
process  has  run  for  an  extended  period  on  the  development 
machine.  The  test  implementation  will  not  be  used  in  the 
standard  system  since  a 'new  communication  package  recently 
replaced  the  particular  typewriter  manager  used.  Fast  processes 
are  currently  being  installed  as  part  of  otner  tasks,  such  as  the 
Restructuring  of  Fage  Control  Task. 

This  task  is  essentially  completed  except  for  final 
documentation.  Its  results  will  be  extensively  utilized  for 
further  test  and  evaluation  in  otner  tasks. 


4.  hign-Level  Description  of  System  Functionality 

As  part  of  any  attempt  to  certify  a system,  it  is  necessary  to 
have  some  description  of  the  intended  functionality  of  the  system 
itself  to  serve  as  a standard  against  which  to  certify.  Several 
members  of  the  project  have  tried  various  notational  schemes  for 
describing  the  functionality  of  various  parts  of  the  system.  A 
representation  of  system  data  bases  and  related  algorithms  in  tne 
Vienna  Definition  Language  was  performed  using  tne  Known  Segment 
Table  as  a case  study.  A similar  descrioticn  of  directory 
control,  using  English  as  tne  descriptive  languace,  was  also 
performed.  Finally,  a language  was  devised  for  describing 
programs  with  complexity  structured  data  bases,  wnicn  attempts  to 
avoid  implications  concerning  the  implementation  cf  the  data  base 
structure.  Tnis  language  is  now  being  used  to  represent  various 
alternative  algorithms  being  considered  as  part  of  the 
restructuring  of  page  control. 


5.  Study  of  the  Removal  of  User  I/O  from  Ring  0 

A strategy  has  been  developed  for  handling  user-initiated  I/O 
which  operates  almost  completely  in  the  user  ring.  The  only 
function  which  is  required  within  the  kernel  is  tne  management  of 
multiplexed  devices.  The  scheme  uses,  as  tne  buffering  stratecy 
for  I/O,  the  virtual  memory  management  algorithm  of  the  system. 
The  scheme  effectively  removes  I/O  from  the  kernel  of  the  system, 
nowever  it  requires  an  I/O  controller  witn  capabilities  slightly 
greater  than  the  one  currently  available  on  Multics.  Thus  this 
particular  scheme  will  not  be  implemented  in  the  near  future.  It 
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is  being  considered  in  the  further  design  of  the  system 


2 . 3 Continuing  Ta s k s 

Tne  tasks  listed  below  remain  active  and  will  be  pursued  in  the 
future  by  the  Computer  Systems  Researcn  Division  of  Project  MAC 
at  MIT. 


1.  Restructuring  of  Page  Control 

Research  is  continuing  on  various  ways  tc  reorganize  page 
control.  Using  the  language  devised  under  the  completed  task 
"Sign  Level  Description  of  System  Functionality",  a version  of 
page  control  was  constructed  which  handled  read-write  seouences 
in  a separate  process.  This  approach  was  then  further  refined  to 
produce  a version  of  page  control  which  uses  separate 
asynchronous  processes  to  execute  all  of  the  oaae  control 
functions  except  the  act  of  fetching  the  missing  page.  It  is 
felt  that  by  isolating  functions  in  separate  orocesses,  and 
constraining  them  by  restricting  the  interprocess  communication 
paths,  that  it  will  be  easier  to  understand  and  certify  tne 
overall  algorithm.  One  of  the  other  oenefits  of  structuring  cage 
control  in  this  way  is  that  it  should  be  possiole  for  several 
processors  to  take  and  narrdle  a page  exception  simultaneously, 
without  interfering  with  each  other. 

The  goal  of  this  task  is  to  utilize  several  asynchronous  parallel 
processes  to  perform  the  'functions  of  page  control.  Separate 
processes  are  used  to  remove  pages  from  memory  and  from  the 
paging  device  so  tnat  a tree  storage  pool  will  always  exist  to  be 
used  for  the  servicing  of  page  faults.  Tne  processes  used  are 
examples  of  the  fast  processes  developed  under  the  completed  task 
"Fast  Processes  in  Ring  0" . Use  of  oarailel  processes  provides 
simplification  of  the  algorithm,  since  it  eliminates  some 
artificial  interactions  that  occur  if  tne  functions  are  performed 
as  part  of  tne  same  process  and  which  constrain  tne  functions  to 
run  in  a particular  synchronized  order.  The  new  method  will  also 
scale  up  more  effectively  to  a larger  system  since  it  eliminates 
contention  on  the  global  page  table  lock. 

Only  two  steps  remain  to  complete  tnis  task.  On  steo,  of  course, 
is  the  final  documentation  in  the  for  of  a technical  reoort.  The 
second  remaining  step  is  an  investigation  of  tne  oerformance 
aspects  of  tne  new  implementation.  Initial  comparisons  between 
the  standard,  currently  operational  Page  ■ Control  and  tnis 
experimental  version  of  Page  Control  suggest  that  the 
experimental  version  requires  aoout  one  and  one  naif  tne  standard 
time  co  process  a page  fault.  It  seems  that  this  increase  in  time 
results  from  the  experimental  version  being  coded  in  PL/I  and  tne 
use  of  a large  number  of  external  subroutine  calls  which 
introduced  considerable  execution  time  overnead.  Tne  true 
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magnitude  of  these  two  differences  will  be  investigated  to 
discover  the  intrinsic  costs  of  the  two  algorithms. 


2.  Restructuring  of  Traffic  Control 


Tecnniques  are  currently  being  explored  to  restructure  and 
simplify  the  traffic  controller  in  order  to  speed  up  the  act  of 
switching  from  one  process  to  another  and  to  simplify  the 
mecnanisms  involved.  The  intention  is  to  split  the  traffic 
controller  into  two  parts,  separating  out  the  actual  act  of 
switching  from  one  process  to  another  from  the  more  complex  act 
of  deciding  which  process  is  eligible  to  run.  The  division  into 
policy  and  mechanism  should  make  the  algorithm  easier  to 
understand .. 


A design  has  been  proposed  to  restructure  the  traffic  controller 
into  two  levels.  The  lower  level  multiplexes  the  real  processors 
of  tne  system  among  a fixed  number  of  so  called  virtual 
processors.  By  fixing  in  advance  tne  number  of  such  virtual 
processors,  tnis  low  level  processor  multiplexor  need  make  no  use 
of  tne  systems  virtual  memory  facilities.  Thus  tnere  is  a strict 
and  ordering  oetween  tne  multiplexor  and  tne  virtual 
higner  level  scheduler  multiplexes  some  of  the  virtual 
among  all  of  the  currently  operating  real  Multics 
, This  higher  level  scheouler  can  use  all  of  the 
of  tne  Multics  virtual  memory,  since  .they  are 
at  a lower  level.  It  is  exoected  that  this 


isolation 
memory.  A 
processors 
processors . 
facilities 
implemented 


restructuring  will  clarify  tne  relationship  between  traffic 
control  and  page  control  and  also  aid  in  separating  the  idea  of 
interprocess  signaling  from  tne  idea  of  traffic  control.  Ir.  this 
proposal,  no  ring  0 data  base  (such  as  the  current  message  table) 
will  be  needed  for  messages  between  processes.  Messages  between 
processes  will  oe  sent  using  segments  that  are  protected  using 


tne  standard  system  access  control 
be  a great  simpl ir ication  over  tne 


mecnanisms.  This 
current  mechanism 


;ears 


Progress  is  being  made  in  four  areas.  First,  the  low  level 
scheduler  whicn  implements  virtual  processors  using  real 
processors  is  being  implemented.  Second,  the  nign  level 
scheduler,  which  will  multiplex  tnese  virtual  processors  among 
real  Multics  processes  is  being  designed.  Third,  all  portions  of 
the  system,  other  than  traffic  control,  which  must  be  modified  or 
redesigned  in  order  to  run  the  new  traffic  controller  have  been 
identified.  Included  are  modifications  to  interrupt  and  fault 
handling,  changes  to  page  fault  handling,  and  various  otner  small 
system  changes.  Recoding  is  in  process.  Fourth,  a proposal  has 
seen  preparea  to  eliminate  from  the  system  tne  traffic  control 
data  base  known  as  tne  Interprocess  Transmission  Taole  (ITT). 
Tnis  removal  would  simplify  the  traffic  controller  s iani f icantly 
and  ce  anotner  step'  in  the  attempt  to  simplify  the  various 
interprocess  communication  mechanisms  being  used  in  Multics. 
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During  this  reporting  oeriod,  no  reportable  proaress  was  made  on 
this  task  due  to  a lack  of  available  manpower. 


3.  Restructuring  of  tne  Answering  Service 

The  answering  service  is  made  up  of  tnose  algor itnms  which 
autnenticate  the  user,  create  processes,  and  manage  teletype 
lines.  This  is  a large  interconnected  set  of  functions,  all  of 
which  are  security  sensitive  given  the  current  modularization.  A 
rearrangement  of  the  answering  service  has  been  proposed  which 
will  achieve  an  isolation  of  tnose  particular  components  that  are 
in  fact  crucial  to  assure  secure  operation  of  the  system.  A 
similarity  has  been  recognized  oetween  the  creation  of  a new 
process  and  the  entering  of  a new  protection  domain.  This  allows 
access  control  lists  to  be  used  to  regulate  the  creation  cf 
processes  on  tne  behalf  of  any  particular  user.  In  aeneral,  this 
scneme  avoids  the  need  for  certified  software  by  providing  the 
means  to  assure  the  user  that  a process  created  with  the  user's 
identification  will  start  executing  only  in  certain  soecifien 
programs  that  tne  user  provides.  These  programs  are  provided 
with  tools  whicn  allow  tnem  to  determine  that  the  process  has 
been  brought  into  execution  under  aoprooriate  c i rcums  tan.ces . 

Curing  this  reporting  period,  all  the  code  required  for  tne 
experimental  redesign  of  the  Answering  Service  was  completed.  The 
testing  and  evaluation  of  tne  new  version  is  proceedinn  in 
parallel  with  tne  documentation  of  tne  design.  Current  scnecules 
project  that  this  task  will  be  completed  in  early  1976. 


4.  iiultics  System  Initialization 

If  one  is  to  certify  t.nat  a svste^  wor  ks  correctly,  one  must 
begin  by  verifying  the  "initial  state"  of  that  system.  For  this 
reason  it  is  very  important  to  understand  now  tne  Multics  system 
initializes  itself.  The  current  initialization  system  is 
relatively  unstructured  and  confusing  and  is  apparently  not 
amenable  to  verification  or  certification.  A proposal  has  been 
made  for  restructur ing  system  initial ization  that  reduces  tne 
amount  of  code  in  the  initialization  pnase  and  that  simplifies 
the  task  of  verifying  the  remainder. 

The  approach  is  to  recognize  that  much  of  what  is  now  considered 
initialization  ought  ratner  to  be  considered  as  reconfiguration. 
Initialization  is  then  decomposed  into  two  pnases.  Tne  first 
onase  involves  getting  a minimal  Kultics  up  and  running.  The 
second  cnase  is  a series  of  reconfigurations  based  on  input 
describing  tne  actual  configuration  in  use.  Tne  advantage  of 
this  strategy  is  that  all  of  the  reconfigurations  run  in  a 
complete,  operations  iiultics  environment,  which  is  much  easier  to 
understand  than  a partial  and  ever  changing  environment  as 
presented  in  the  various  stages  of  the  current  initialization 
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procedure.  Also,  since  the  minimal  Multics  is  independent  of  the 
actual  configuration  (given  the  minimum  hardware  required),  it 
can  be  largely  generated  as  the  system  tape  is  created. 
Algorithms  wnich  run  at  the  time  that  the  system  tape  is  created 
are  .easier  to  verify  since  they  too  run  in  a fully  operational 
Multics  environment. 

Coding  and  design  verification  of  this  task  significantly 
progressed  during  the  past  six  months.  Initial  verification  of 
the  design  approach  of  structuring  system  initialization  as  a 
collection  of  sequential,  dynamic  reconfigurations  of  appropriate 
nardware  and  software  subsystems  is  currently  being  verified. 
Design  documentation  is  expected  in  early  1976. 

5.  Multitasking  in  the  User  Ring 

This  task  will  provide  an  environment  that  will  allow  the  user  to 
write  various  programs  as  if  tney  were  executing  in  separate 
cooperating  processes.  The  execution  of  these  processes  is 
supported  oy  multiplexing  the  one  single  process  of  the  user. 
Thus,  tnis  is  described  as  multitasxing  rather  than  as 
multiprocessing.  The  creation  of  tnis  program  environment  in  the 
user  ring  does  not  directly  contribute  to , s impl if ication  of  the 
kernel,  but  tne  existence  of  the  facility  will  allow  otner 
modifications  that  will  simplify  the  kernel.  Among  tnese  is  the 
design  of  a simple  but  effective  quit  handling  mechanism  to 
replace  the  current  complicated  mechanism  for  multiplexing  ARPA 
Network  server  processes,  and  in  the  restructuring  of  'the 
answering  service. 

Cr.a  experiment  involved  implementation  of  a version  of  user  ring 
Interprocess  Communication  (IRC)  as  part  of  an  experimental 
command  processor.  In  this  version,  the  command  processor  runs 
each  command  in  a separate  task,  when  a quit  is  signalled  in  tne 
user's  process,  the  result  is  that  only  one  task  need  be 
suspended  and  control  returned  to  tne  listener.  Any  new  task 
(command)  started  will  run  on  a different  stack,  thus  signal 
handlers  for  various  tasks  never  become  confused  and  it  is 
possible  to  restart  any  task  in  any  order  with  any  number  of 
otner  tasks  suspended.  Another  experiment  involved 
implementation  of  an  experimental  version  of  the  Network  server 
process . 

The  multitasking  environment  in  the  user  rinq  is  completed  and  is 
usable,  but  it  remains  an  experimental  function  requiring  further 

test  and  evaluation  as  well  as  final  documentation. 


14 


6.  A Methodology  for  Designing  Computer  Systems 

This  task  has  been  concerned  with  developing  a general 
methodology  for  designing  certifiably  secure  systems.  The  goal 
is  to  make  the  systems  easier  to  certify  as  correct.  A metnod 
nas  been  formulated  and  is  being  tested  by  attempting  to  design  a 
security  kernel  for  a system  with  functional  characteristics 
similar  to  Multics.  The  basic  design  is  complete  and  some  of  the 
abstract  programs  have  been  written  in  the  CLU  language  (which 
resulted  from  the  completed  task  "High  Level  Description  of 
bystem  Functionality").  Nor*  is  under  way  to  maxe  tne 
verification  of  the  resulting  system  easier  and  on  improving  tne 
efficiency  of  the  resulting  system  without  making  the 
verification  harder. 

Documentation  of  the  methodology,  design  of  the  Mul tics-like 
system,  and  other  results  are  in  Drocess  and  will  aooear  early  in 
1976. 


7.  Study  of  Multics  Security  holes 
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distrioution  by  its  very  sensitive  nature. 


8.  Restructuring  the  Network  Control  Program 

The  Network  Control  Program  has  represented  an  ideal  candidate  to 
use  in  an  experiment  involving  a multiple  process  implementation 
of  a control  algorithm,  as  discussed  under  "Multitasking  in  the 
User  Ring".  The  hetworx  Control  Program  is  concerned  with  tne 
flow  of  data  to  and  from  tne  AP.PA  Network.  Its  princiole 
function  is  the  management  of  a multiplexed  communication  path, 
wnich  implies  the  management  of  multiplexed  buffers.  It  was 
proposed  that  tne  flow  of  cata  between  these  various  buffers  oe 
implemented  using  tne  fast  processes  in  ring  0. 
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A related  area  is  the  possibility  that  common  elements  may  be 
identified  in  the  software  that  is  required  to  handle  different 
multiplexed  communication  streams.  It  is  possible  that  there  is 
a similar  function  in  the  software  that  interfaces  the  ARPANET 
and  the  355.  A buffer  manager  routine  is  an  obvious  example  of 
a possible  common  routine.  It  is  very  interesting  and  profitable 
to  identify  these  modules  and  to  isolate  them. 

This  markedly  reduced  the  amount  of  code  within  tne  kernel. 
Also,  if  all  multiplexed  communication  streams  could  be  handled 
by  one  set  of  kernel  modules,  such  as  the  network  server,  this 
could  result  in  great  simplification  of  the  kernel.  This 
ODservation  also  has  led  to  the  start  of  a general  re-examination 
of  the  way  that  I/O  is  done  by  the  system. 

The  restructured  Network  Control  Program  was  installed  durinq 
this  reporting  period.  Only  final  documentation  of  tnis  task 
remains . 


9.  New  I/O  Buffer  Strategy 

This  "task  involves  the  design  and  implementation  of  a new  I/O 
buffering  strategy  which  uses  the  virtual  memory  itself  as  a 
buffer.  The  task  has  become  part  of  the  task  of  restructuring 
the  Network  Control  Program.  Tne  task  arose  from  an  attempt  to 
increase  the  efficiency  of  transmitting  data  to  and  from  the  ARPA 
Network  and  at  the  same  time  to  gain  a more  basic  understanding 
of  the  interaction  between  Input/uutput  functions  and  virtual 
memory  computer  systems. 

The  result  of  tnis  design  is  a buffer  that  uses  the  virtual 
memory  and  appears  to  be  infinite  in  length.  The  use  of  the 
virtual  memory  eliminates  any  need  to  compact  or  otherwise  manage 
tne  buffer  area,  thus  reducing  overhead.  Since  tne  buffer  is  in 
the  process  virtual  address  space,  it  is  directly  accessible  to  a 
user  process.  This  avoics  tne  copying  of  data  to  mane  it 
accessible . 

It  appears  that  this  I/O  buffer  strategy  can  be  exploited 
successfully  for  all  devices  for.  which  the  system  nucleus  is 
responsible.  This  unification  of  buffer  management  is  a 
significant  contribution  to  tne  certification  project  due  to  its 
reduction  of  bulk  and  complexity  in  tne  kernel. 

Tnis  task  progressed  from  the  conceptual  pnase  to  tne  design 
phase  during  tnis  reporting  oeriod  in  tnat  tape  I/O  services  are 
being  considered  tnrougn  the  ARFA  Network  interface  to  determine 
the  magnitude  of  tnruput  dearadation. 


1G.  Formulation  of  Criteria  for  Inclusion  of  Modules  Within  the 
Kernel 


This  task  is  an  attem.pt  to  identify  a set  of  general  rules  which 
will  specify  those  modules  which  must  be  within  the  kernel  of  an 
operating  system.  One  approacn  is  a study  of  the  separation  of 
policy  from  me c nan  ism  in  a nodule. 

As  part  of  tnis  task,  a discussion  of  the  criteria  to  be  used  for 
including  portions  of  tne  page  control  system  witnir.  the  Kernel 
has  been  produced.  Tne  intent  is  to  perform  a similar  study  for 
various  other  portions  of  the  system  and  to  attempt  to  evolve  a 
general  theory  of  the  structure  of  a kernel  from  them. 

Tnis  task  was  completed  during  this  reporting  period  and  final 
documentation  will  appear  in  tne  "Methodology  for  Designing 
Computer  Systems"  task  above. 

• ' - . j 

11.  Stuoy  of  System  Error  Recovery 

Tne  system's  ability  to  recover  from  errors  is  related  to  tne 
proolem  of  system  initialization  since  bctn  must  assure  or 
certify  tnat  the  system  is  in  some  known  state.  This  task  is 
interested  in  determining  whether  there  are  some  particular 
structures  tor  data  bases  and  algorithms  that  maxe  it  much  easier 
to  assure  that  the  data  base  is  in  fact  consistent  and  correct. 

This  task  was  combined  witn  the  "Study  of  the  Relationships 
oetween  Security  and  Rel iabi 1 it y"  task  oelow  during  this 
reporting  period. 

IT.  Study  of  Relationships  oetween  Security  and  Reliability 

Tnis  task  involves  studying  the  relationsnio  between  tne  security 
of  a system  and  the  reliaoility  of  that  system.  In  the  Kultics 
system,  it  is  presumed  that  a system  failure  may  have  an  unknown 
effect  on  tne  security  status  of  tne  system;  this  is  the  reason 
tnat  the  system  is  shut  down,  salvaqec,  and  restarted  after  every 
unexplained  system  failure.  It  is  not  obvious,  however,  that 
security  is  directly  dependent  on  reliability.  If  it  were 
possible  to  determine  that  certain  classes  of  computer  failure 
could  not  influence  the  security  state  of  the  system,  then  the 
two  functions  would  have  nothing  to  do  with  each  other.  More 
strongly,  it  is  possible  that  a highly  reliable  system  contains 
mechanisms  tnat  are  not  desirable  from  the  viewpoint  of  security, 
for  example,  one  way  to  increase  the  reliable  storage  of 
information  on  a system  is  to  make  several  cooies  of  that 
information;  many  copies,  however,  increase  tne  crobaoility  that 
tne  information  may  oe  compromised. 
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In  an  attempt  to  understand  better  tne  relationship  between 
security  and  reliability,  a study  has  begun  of  a variety  of 
systems  tnat  maintain  high  reliability  as  one  of  their  goals,  to 
investigate  mechanisms  in  the  system  in  the  lignt  of  t.neir 
implications  for  the  security  of  tne  information  stored  on  that 
system.  The  tasi<  has  been  combined  with  the  Study  of  System 
Error  Recovery  task  above. 

During  this  reporting  period,  initial  design  documentation  was 
prepared  and  is  being  reviewed. 


13.  Removal  of  the  Storage  Hierarchy  from  Ring  0 

The  removal  of  the  linker  and  of  name  space  management  from  ring 
0 can  be  considered  the  first  two  steps  in  restructuring  the  file 
system.  The  next  logical  step  is  the  removal  of  directories  from 
ring  C.  Study  has  shown,  however,  that  this  is  not  appropriate 
at  t.nis  time. 

During  tnis  reporting  period,  a comprehensive  review  of  tne 
Kultics  Storage  system  was  undertaken.  Tnis  project  was  led  by 
t'ilT  personnel  and  was  also  attended  oy  cognizant  Honeywell 
personnel.  This  group  study  reviewed  the  Hew  Storage  System  as  it 
was  being  designed  and  implemented.  Specifically,  the  Directory 
Control  subsystem  and  the  functions  of  its  related  data  oase, 
the  Active  Segment  Table  (AST),  were  intensively  studied.  The 
purpose  of  this  study  was  to  understand  the  reasons  behind  the 
large  bulk  and  complexity  of  these  facilities  and  to  eventually 
propose  strategies  for  simplification.  It  is  expected  that  the 
output  of  this  study  will  be  a variety  of  prooosals  for 
additional  researcn  in  various  areas  related  to  tnese  tooxcs. 
One  immediate  spinoff  from  this  study  was  the  task  to  seoarate 
tne  Page  Control  and  Segment  Control  functions  witnin  tne  Active 
Segment  Tacle  to  provide  further  simplification  of  Page  Control. 
This  last  task  surfaced  during  this  reporting  period  and  orogress 
in  tne  form  of  initial  design  considerations  was  identified  late 
in  tne  period. 

It  has  been  proposed  that  directory  control  be  partitioned  into 
two  components,  each  with  its  own  data  base.  There  will  be  an 
unstructured  segment  catalog,  indexed  by  unique  identifier.  This 
catalog  maintains  the  physical  attributes  for  each  segment  such 
as  file  map,  bit  count,  varipus  date-time  parameters,  etc.  There 
will  also  be  a directory  hierarchy  which  maintains  the 
association  between  character  string  names  and  unique 
identifiers.  This  nierarchy  will  also  maintain  the  access 
control  list  for  eacn  segment.  The  principle  cnange  in  this 
proposal,  relative  to  earlier  oroposals,  is  that  the  access 
control  list  will  be  stored  in  the  directory  hierarchy  rather 
tnan  in  a separate  access  hierarcny. 
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This  task  proceeded  from  task  formulation  and  definition  to 
stuoy,  review,  and  proposal  during  the  past  six  montns.  Initial 
design  documentation  will  be  prepared  in  the  near  future. 


14.  Support  of  User  Defined  Object  Types 

A directory  can  be  considered  as  an  object  defined  in  terms  of  a 
lower  level  object,  the  segment.  It  is  possible  that  the 
mechanisms  that  define  the  directory  could  be  generalized  to 
allow  the  definition  of  new  object  types  defined  by  users.  This 
sort  of  ability  has  been  provided  in  systems  that  are  based  on 
capabilities,  but  not  in  systems  that  are  based  on  access  control 
lists.  This  task  has  been  considering  the  question  of  whether 
user  defined  object  types  can  be  supported  in  a system  such  as 
Mu 1 tics . 


There  are  two  projects  in  this  area.  first,  consider aticn  of  how 
extended  objects  can  be  supported  using  an  appropriate 
combination  of  access  control  list  and  capability  cased 
mechanisms . Second,  the  implementation  of  user  defined  ociects 
in  a pure  access  control  list  environment.  This  project  is 
considering  what  policies  for  protection  can  be  imposed  upon 
tnese  user  defined  extended  objects. 


Little  reportable  progress  was  made  on  this  task  during  tnis 
reporting  period  due  to  a lack  of  available  manpower. 


15.  Multics  Performance  Benchmark 

As  tne  tasxs  of  simplifying  the  system  are  accomplished  and 
further  modifications  to  the  system  are  proposed,  it  is  important 
to  be  3ole  to  determine  tne  performance  effects.  A stable  and 
reliable  performance  meter  is  needed. 


Two  projects  have  been  underway.  Cne  involves  rework  of  the 
standard  Multics  performance  benchmark.  There  is  now  a version 
of  tne  benchmark  that  can  be  debugged  on  line  and  is  extremely 
stable  in  the  virtual  cpu  time  required  for  the  run.  The  ot.ner 
project  involves  creation  of  a system  load  generator.  All  test 
load  generators  which  have  existed  for  Multics  in  tne  past  have 
suffered  from  one  of  two  drawbacks;  either  they  use  absentee  jobs 
to  generate  t.neir  lead  (which  does  not  exercise  the  I/O  system) 
or  they  require  a large  number  of  telephone  data  sets  (which  is 
very  expensive) . A load  generator  has  been  develooec  that  can  be 
run  using  the  AAFANfcT  to  drive  the  test  processes.  Tnis  is 
useiul  as  it  includes  a test  of  tne  I/C  system. 


This  task  progressed  curing  this  reporting  period  in  that  further 
refinement  and  definition  of  tne  oenchmar*  contents  was 


implemented . 
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16.  Independent  Domains  and  Breakproof  services 

'ibis  task  is  exploring  some  of  the  implications  of  removing 
certain  traditional  supervisor  functions  from  tne  Multics 
security  kernel  and  is  exploring  an  extension  of  tne 
functionality  of  the  Multics  protection  mechanisms  to  allow 
multiple,  independent  domains  to  be  part  of  one  process. 

A traditional  supervisor  includes  many  mechanisms  that  are  not 
security  sensitive  simply  to  protect  these  mechanisms  from 
accidental  damage  from  user  errors.  To  produce  a security  kernel 
for  Multics,  many  sucn  mechanisms  are  being  moved  out  of  tne 
supervisor.  By  moving  them  to  the  user  environment,  mechanisms 
such  as  tne  linker,  the  reference  name  manager,  and  the  search 
rules  become  breakable,  which  could  make  the  system  harder  to 
use.  Fortunately,  the  Multics  protection  rings  provide  a place 
to  protect  non-xernel  mechanisms  tnat  should  be  creakcroof.  Tney 
can  execute  in  a ring,  say  ring  2,  aoove  the  kernel  but  below  tne 
normal  user  ring.  Because  all  data  oases  managed  by  these 
service  mechanisms  are  private  to  a crocess,  tney  are  not  part  of 
the  security  kernel  and  need  not  be  certified,  yet  they  cannot  be 
oroken  inadvertently  by  user  errors.  Fart  of  this  orcject  is  tne 
determination  as  to  now  to  provide  such  breakproof  services  for 
Multics . 

The  second  aspect  of  this  project  concerns  protected  subsystems. 
Multics  has  always  supported  user-defined  protected  subsystems, 
although  the  protection  rings  can  provide  only  one  way 
protection.  It  is  not  possible,  however,  to  use  tne  rings  to 
protect  both  subsystems  and  breaxoroof  services  at  tne  same  time 
in  the  same  process  without  making  the  breakproof  services  common 
to  all  subsystems  in  a process  and  tnerefore  part  of  the  security 
Kernel  for  tnose  subsystems.  Tne  essential  difficulty  is  tne 
total  ordering  of  privilege  implied  by  the  orotecticn  rings. 
Tnus,  to  provide  breakproof  services  some  other  way  must  be  found 
to  orotect  subsystems,  if  the  f unctional i ty  of  protected 
subsystems  is  to  be  maintained.  Tne  method  oeinq  explored  is 
simulating  multiole  independent  domains  (containing  rings)  in  a 
process  using  multiple  descriptor  segments  for  a process.  Inis 
project  is  just  beginning  and  progress  is  continuing. 


2 . 4 Conclusion 

This  section  of  this  progress  report  has  presented  tne  tasks  of  a 
large  research  project  to  evolve  tne  Multics  supervisor  into  a 

security  kernel  which  is  capable  of  supoortinq  tne  functionality 
of  Multics  completely  and  efficiently.  Tne  broad  objective  is 
finding  ways  to  reduce  the  sice  and  complexity  of  tne  software 
tnat  must  be  correct  for  a snared  qeneral-pur pose  system  to  be 
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secure.  Reduced  size  and  complexity  of  security-relevant 
software  is  a prerequisite  to  performing  a convincingly  logical 
verification  that  the  system  correctly  implements  the  claimed 
access  constraints. 
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3.U  btEtr  HARDWARE  ACTIVITIES 


Current  computers  utilized  for  Information  Storage  ana  Retrieval 
(IS&R)  and  Com.munica  tions  applications  are  fundamentally 
incapable  of  providing  adequate  security  protection  for 
concurrent  processing  of  DoD  multilevel-classified  information. 
The  current  approach  of  proviaing  either  physical  separation 
(multiple  facilities)  , or  temporal  separation  (witn  intermediate 
sanitization),  is  prohibi ti vely  costly  for  the  typically  large 
scale  systems  requireo. 

The  Front-End  Processors  to  be  utilized  with  secure  large  scale 
IS&R  systems  and  computer  utilities  require  multilevel  security 
in  order  to  extend  the  security  perimeter  to  include 
communications. 


Tne  solution  to  this  problem  is  based  on  security  design  concepts 
which  are  demonstrably  sufficient  to  effect  a secure  system 
design  which  is  certifiable  and  does  not  or on ibi ti vely  dearade 
performance. 

Tnis  part  of  tne  Secure  dultics  Design,  Development  and 
Certification  Program  encompasses  the  initiation  of  the  desian 
and  development  and  prototype  fabrication  plans  for  a militarized 
Secure  Communications  Processor  (SCOMP) . A specific  application 
has  been  identified  which  will  demonstrate  the  functionality  of 
the  SCOMP.  This  application  is  to  function  as  Secure  Front  End 
Processor  (SFEP)  for  a prototype  secure  machine  of  the  Honeywell 
Series  60  Level  6b  Multics  class  in  a communications  network 
environment.  Tne  SFEP  will  accordingly  include  tne  interface 
unit  to  tne  host  machine.  Also  included  is  initiation  of 
Hardware  verification  plans,  development  of  militarization  clans 
and  plans  for  communications  network  interfaces. 

Tne  design  approach  for  the  SFEP  is  oased  on  concents  derived 
during  tne  previous  phase  of  tnis  contract.  These  concepts  are 
in  turn  based  on  the  Reference  monitor  concent  a'evelooed  oy  tne 
Air  Force  (and  otners)  (2)  whicn  implements  tne  access  rules  and 
algoritnms  of  the  Sell  and  Laradula  math-model.  (3)  The 
math-model  in  turn  models  the  access  rules  of  the  DoD  Information 
Security  System.  The  math-model  is  a representation  of  finite 
discrete-state  mecnanisms  wherein  state-transitions  are 
explicitly  governed  oy  rules  of  the  model.  Since  the  math-model 
is  a discrete-state  mrodel , it  is  correlatabie  to  digital  computer 
system  a r cn i tec tures. 

wnile  tne  functional  requirements  of  tne  Reference-Monitor  may  oe 
performed  interpretively  (in  software),  performance  and 
certif  iaioil  ity  require  tnat  the  functions  be  carefully 
distributed  among  hardware  and  software  implementation  in  crcer 
to  effect  a useful  system.  The  computer  architecture  selected  is 
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based  on  tne  established  isolation  and  mediation  necnanisms  cf 
the  nultics  system.  Tne  following  specific  Multics  Hardware 
features  are  noted: 

1.  Virtual  memory  system 

2.  high  speed  cache  for  ciescriptor  storage 

3.  hierarchical  domains  (rings) 

4.  hardware  supported  ring  crossing 

3 . 1 PFEP  Hardware  Objectives 

The  objectives  of  this  phase  cf  the  1975  program  were  to  initiate 
tne  design,  plan  for  design  verification,  anc  plan  for 
taorication  of  prototypes  of  an  STEP  for  use  with  the  Honeywell 
6G0G/Series  60  computers. 

The  fcFEP  effort  encompassed  five  major  tasks  as  follows: 

1.  Minicomputer  Selection 

Tne  oojective  of  this  task  was  to  select  a suitaole 
commercial  computer  case  for  tne  range  of  applications 
delineated,  wnicn  is  securable  and  mi 1 iea r izable . 

2.  Security  Protection  module  ( S PP1  )< 

The  oojective  of  tnis  task  was  to  initiate  design  of  an  SP !: 
wnicn  can  be  integrated  into  the  selected  computer  case  to 
add  tne  necessary  security  controls  whicn  will  effect  a 
useful  secure  computer  system. 

3.  tjCb'MP  Lesign 

The  oojectives  of  this  task  were  threefold: 

A.  Conf iquration  3nd  Interface  Considerations 

The  objective  of  this  subtask  was  to  plan  to  augment  the 
SFEF  to  induce  communications  network  interface 
capabi 1 i ties . 

ii.  Analysis  Considerations 

Tne  objective  cf  tnis  subtask  was  to  delineate 
preliminary  Hardware  performance  degradations  due  to  the 


_ mmmm 


C.  Militar ization  Consioerations 

The  objective  of  this  subtask  was  to  initiate  the 
development  ' of  desiqn  requirements  for  TEMPEST  and  E i-.C 
compatibility . 

4.  6000/Series  60  Interface  Unit  Design 

The  objective  of  this  task  was  to  initiate  the  design  of  an 
interface  unit  which  will  permit  interfacing  tne  SCOMF  to 
honeywell  60C0/Series  6C  large-scale  computers. 

5.  SCOMP  hardware  Verification 

The  objective  of  this  task  was  to  investigate  techniques 
suitable  for  (a)  Hardware  Verification;  and  (b)  Deriving  a 
probabil istic  measure  of  security  compromise  due  to  nardware 
- failure. 


3.2  Technical  Approach 


SFEP  Functional  Design 

The  SFEP  Security  approach  was  to  base  SFEP  Security  requirements 
on  tne  concepts  delineated  in  the  Architecture  Study  Final  Feport 
of  tne  previous  phase  (18).  The  approach  for  selection  of  tne 
minicomputers  and  the  preliminary  aesigns  for  both  the  SPA  and 
6Q0C/Series  60  Interface  Unit  (ID)  were  to  base  them  on  both  tne 
requirements  of  the  Secure  Communications  Processor  Functional 
opecif ication  cevelcped  during  tne  previous  phase  and  the 
delineated  applications  (19).  The  approach  to  deriving  tne 
ultimately  recommended  specific  implementations  of  the  a PM  and 
6000/Series  6C  10  per  the  SCCwP  specification  was  then  based  on 
tne  selected  minicomputer  and  numerous  tradeoffs  conducted  under 
Air  Force  guidance.  Detailed  functional  specifications  (Design 
Specifications,  Part  I documents)  were  then  developed  for  both 
tne  SPN  and  6GC0/Series  6C  IU. 


SFEP  Environmental  Design 

Tne  SFEP  Environmental  Design  is  based  on  the  Honeywell 
kuggedized  Level  6 computer  now  in  development  at  Honeywell's 
Aerospace  and  Defense  Group  (A DC).  (See  Appendix  A).  This 

ruggedized  Level  6 computer  is  functionally  based  on  and  is 
compatible  with  Honeywell  Information  System's  (HIS)  commercial 
line  of  minicomputers.  Five  major  areas  of  modifications  for 
r uggedization  are  listed  below; 
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. New  Cnassis  Design 

2.  Circuit  Card  Stiffening 

3.  Option  of  Pin  and  Socket  Connectors  at  Bus  Interface 

4.  Power  Supply  Mounting 

5.  New  Control  Panel 

Ihe  designs  developed  for  these  modifications  are  directly 
applicable  to  the  additional  SPN  and  6000/Series  60  IU  boards  and 
mocules  required  for  the  SFEP. 

The  rugged  minicomputer  will  be  qualified  by  Honeywell  to  its 
Design  Specifications  (C3),  Part  1.  A more  detailed  descriotion 
of  the  rugged  minicomputer  program  is  included  as  Appendix  A. 

Tne  TEMPEST  Lesign  aoproacn  developed  control  plans  that  provide 
tne  design  guidance  necessary  for  compliance  with  REE/DLACK 
separation  arm  TEMPEST  compatibility. 

Similarly,  tne  EMC  design  approach  developed  control  plans  that 
provide  tne  design  auidar.ce  necessary  for  compliance  with 
iviIL— STD- 46lrt  and  MIL— STD— 462. 


3 . 3 .-'.a  j o_r  Accompli snments 

The  following  sections  describe  the  details  of  tne  individual  Air 
force  Statement  of  Work  tasks  required  to  initiate  tne  SrLP 
design.  Tne  tecnnical  approach  to  tne  tasks  is  describee  and 
accomnl is.nments  are  delineated. 


3.4  Minicomputer  Selection 


An  analysis  was  performed  which  defined  tne  criteria  by  which  a 
trade  study  could  be  done.  Tnese  criteria  were  in  the  form  of 
requirements  placed  on  tne  commercial  minicomputer. 

The  top  level  requirements  affecting  the  minicomputer  selection 
are  summarized  as  follows: 


Functional  Requirements 

1.  The  arc.nitecture  snoulc  be  bus-structured  to  support  an 
essentially  autonomous  Security  Protection  Hoauie  (s?;  ). 

2.  The  architecture  should  nave  basic  functionality  such 
that  the  minicomputer,  supported  by  tne  S PM , will 
provide  tne  functionality  required  for  effective 
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implementation  of  a Reference  Monitor.  This  includes 
multiple  machine  states,  fast  context  switching, 

suitaole  address  space  definition,  real-time  support  and 
interprocess  communication  features. 

3.  The  selected  computer  must  have  sufficient  performance 

to  satisfy  the  Front  End  Processor  application 

requirements  for  the  Honeywell  6000/Series  60  computers 
including  Multics. 

4.  Tne  selected  computer  must  be  suitable  for  a range  of 
communications  processor  applications. 


Other  Requirements 

5.  Environmental  Requirements 

The  selected  computer  snould  be  compatible  witn,  or 
modifiable  to  be  compatible  with,  a range  of  selected 
physical  and  electrical  military  environmental 
specifications  applicable  to  SFEP  and  SCCMP 

applications . 

6.  Product  Support 

The  selected  computer  should  have  continuing  corporate 
product  support  throughout  the  useful  life  of  the 
6000/Ser ies  60  family  of  computers . 

The  selection  metnodology  was  to  select  a candidate  set  and 
develop  a tradeoff  matrix  of  candidates  versus  pertinent 
non-sub jective  attributes. 

It  may  be  noted  that  many  candidates  could  ce  summarily 
eliminated  due  to  criteria  5 and  6 above. 


Recommendation 

The  Honeywell  Level  6 computers  with  their  ruagedizea 
counterparts  were  selected  as  the  comouters  which  best  satisfy 
tne  salient  requirements.  Within  the  Level  6 family,  the  NML-15C 
was  selected  as  the  baseline  for  the  initial  SFEP  application. 
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Task  Output 

An  in-depth  discussion  of  requirements,  candidates,  tradeoff 
methodology  and  selection  recommendations  is  given  in  the 
engineering  tradeoff  study  "Cesiqn  Analysis  for  a Rul tics  becure 
Front  End  Frocessor" , now  in  preparation  as  an  ESD  Technical 
Kepor  t . 


3 . 5 SPh  Design 

The  SCOHP  specification  is  a generic  functional  specification 
which  defines  the  functionality  required  for  implementation  of  a 
multilevel  secure  communications  processor  via  F.ef  er  ence-Mon  itor 
(2)  functionality. 

The  approach  for  beginning  the  design  of  the  SPA  was  to  perform 
specific  (top-level)  hardware  implementation  of  an  essentially 
autonomous  SPH  suitable  for  integration  into  the  selected 
minicomputer  base  and  perform  implementation  tradeoffs.  This 
preliminary  design  was  supported  oy  development  of  the  baseline 
Detailed  specifications  (Db)  Fart  I. 

The  major  tradeoffs  considereo  were  as  follows: 

1.  Distributed  control  Ionic  versus  micro-programmed 
control  logic. 

2.  happed  I/C  versus  pre-mapped  I/O 

3.  Long  address  form  versus  snort  address  form  for  virtual 
u'jsr ess  s £ ci c '3 

4.  several  Cacr.e  configurations 

.r.e  trameori  uata  *as  presented  at  technical  intercnar.ge  meet i nos 
ana  tr.e  following  implementation  oecisions  were  mace: 

1.  i-.icro-proarammec  control 

2.  happed  I/O 

3.  Long  address  form 

uased  on  these  aecisions  and  functionality  refinements,  the  CS 
Fart  I specification  was  updated  to  define  the  current  design 
requirements  of  tne  bp;-,. 
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Task  Cutout 


The  design  specification  for  the  SPM  provides  a detailed 
functional  definition  of  the  current  SPM  implementation.  This 
document  was  submitted  to  the  Air  Force  as  "Security  Protection 
Lnit  Specification".  It  is  now  in  preparation  for  publication  as 
a Configuration  Item  Development  Specification. 


3 . 6 SCOHP  Design 

3.6.1  Configuration  and  Interface  Considerations 

The  objective  of  this  task  was  to  delineate  top  level  hardware 
interface  and  configuration  functional  requirements  for  the  SCOMF 
for  the  following  applications: 

1.  The  SC CMP  should  be  capable  of  simultaneously  supporting 

a variety  of  terminals  in  both  half-duplex  and 
full-duplex  mode  at  speeds  including  11C,  134.5,  150, 

300,  1 20C , 2400,  4800,  and  9600  cits  per  second. 

2.  The  SCCMP  should  support  multiple  terminals,  modular ly 
expandable  to  a maximum  of  256  (althouah  this  may 
require  multiple  processors  working  together). 

3.  The  SCOHP  must  support  various  external  I/C  devices. 

4.  Consideration  and  planning  for  the  design  of  brassbcard 
communications  network  Ill's  for  SATIN  IV,  Autodin  II  and 
the  ESD  Secure  Communications  Controller  (SCC) . 


0 o m m unications  Met w crss 

The  studies  indicate  tne  most  cost-effective  ascroacn  to 
interfacing  to  tne  various  cor.munica tions  networks  is  via  the 
standard  product-line  communications  support  modules  such  as  tne 
multiline  communications  controller  (MLCC)  and  communica tions 
1 ir.e-adapter s . 

Tne  MLCC  is  microprocessor-based  and  thus  is  programmable  and 
nignly  adaptable  to  different  line  protocols;  message  text 
delimiting,  editing,  and  checking;  and  communications  line 
adapters . 

Salient  cnaracter istics  of  tne  MLCC  are  as  follows: 

1.  Lip  to  eight  full  duplex  10.8K  bit  lines  in  pairs  per 
MLCC  (cr  two  56  K bitv  lines,  or  one  72 K bit  line). 
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2.  User  programmable  to  provide  for  message  delimiting, 
message  editing,  and  various  cneckina  algorithms. 

3.  hardware  cnecking  (L PC,  CRC,  etc.). 

I 

4.  Individual  Direct  Memory  Access  (DMA)  for  each  line  and 
transmission  direction. 

The  following  line  adapters'may  be  utilized  for  each  channel: 

1.  Asynchronous  with  KS232-C  interface.  Speed  selectable 

by  software  for  any  of  the  following  bit  per  second 
rates:  50,  75,  110,  134.5,  15C,  300,  60 G,  900,  1200, 

1800,  2400,  3600,  4800,  7200,  9600. 

2.  Synchronous  with  RS232-C  interface.  Up  to  10. 8K  cits 
per  second  including  BSC  capabilities. 

3.  Synchronous  witn  MIL-STD-186-C  interface.  Up  to  1G.SK 
bits  per  second  including  BSC  capabilities  (one  line  per 
adapter ) . 

4.  Direct  connect  synchronous  up  to  10. 8K  bits  per  second. 

5.  Broad  band  synchronous  with  Dell  301,  303  type  interface 
(one  line  per  adapter). 

6.  Honeywell  Data  Link  Controller  with  F.S232-C  interface 
(one  line  per  adapter). 

7.  Bell  801C  auto  dial. 


Peripheral  Devices 

Since  the  Level  6 computer  family  is  a general-purpose  product, 
a variety  of  u.nif-recorc,  random  access,  and  culk  storage 
peripr.eral  devices  are  suoported.  These  are  suitable  for 
"external"  I/O  in  the  6000/Series  60  context.  Peripherals  of 
performance  magnitude  suitaole  for  Multics  "internal"  I/O  in 
general  are  not  supported  and  would  require  custom  controllers. 


Conclusions 

In  general  the  proauct-suooor ted  communications  controllers 
availaole  with  the  Level  6 computer  family  will  permit  direct 
hardware  interfacing  to  tne  SATIN  IV,  Autodin  II  and  A R PA 
networks  with  at  present  only  one  notable  exception.  The  MLCC 
provides  a 16  bit  Circular  Redundancy  Check  (CRC) , whereas 
Autodin  requires  a 32  bit  CRC.  Inis  will  recuire  some  hardware 
modification . 
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In  addition,  depending  upon  the  network  entry  points,  whicn  is 
application  dependent,  custoir,  adapter  cards  and  software  drivers 
may  be  required. 


3.6.2  SCOi'iP  Design  Performance  Analysis  Considerations 

The  objective  of  this  task  was  to  initiate  performance  analyses 
for  the  SFEP. 


Approach 

The  principle  causes  of  performance  degradation  due  to  the  S PM 
were  determined  to  he  due  to  tne  following: 

1.  The  additional  delay  in  each  reference  to  memory  due  to 
the  SPM. 

2.  Tne  time  required  to  load  tne  ultimate  SDt.'  in  cache  upon 
data  descriptor  fault. 

3.  The  time  required  to  lead  descriptor  ease  roots. 

4.  Tne  additional  time  required  for  inter-procedure 
transfers  due  to  ring  crossing  barriers. 

A comprenensi ve  analysis  has  net  yet  been  performed  since  it  is 
both  hardware  configuration  and  application  dependent.  However, 
several  assertions  may  be  made  as  follows: 


memory  Access  Delay 

Assume  a delay  of  ICC  or  25C  r.s  delay  per  memory  access 
(depending  upon  whetner  tne  descriptor  was  located  in  fast  Access 
otore  (BAs)  or  3ac*  Up  Storage  Cache  (SUoC) ) and  a memory  cycle 
time  of  750  ns.  Also  assume  90%  of  cescriotor  hits  are  in  FAS 
and  a typical  60%  to  80%  of  system  order  time  is  limited  ov 
memory  accesses,  tnen  a performance  loss  due  to  this  component 
would  be  on  tne  order  of  12%.  The  remaining  time  delays  are 
application  dependent  and  occur  relatively  infrequently  and  are 
small  in  comparison. 

Conclusion 

The  overall  performance,  with  a degradation  limit  of  no  more  than 
25%  as  specified  py  the  SCCkp  specification,  appears  readily 
acnievaole . 
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Test  ana  Evaluation  Software 


An  additional  objective  of  this  task  was  to  plan  for  the  eventual 
test  and  evaluation  of  the  SfEP  hardware  utilizing  software 
designed  ana  developed  for  the  purpose  of  test  and  evaluation, 
‘inis  test  and  evaluation  software  is  described  in  the  Test  and 
Evaluation  Software  Plan,  dated  January  13,  1970. 


3.6.3  SCOMP  Design  Militarization 

Tne  major  objective  unaer  this  subtask  was  to  develop  initial 
TEMPEST  ana  EMC  design  specifications  for  a militarized  SCOflP. 


TEMPEST 

The  initial  system  design  effort  was  the  definition  of  tne 
ADD/ BLACK  requirements.  It  is  considered  that  a typical 

situation  would  find  the  SCGMP  operating  in  a secure  RED  area 
with  both  high  and  low  speed  RED  lines  and  low  to  medium  speeu 
BLACK  lines.  High  speed  and  low  speed  are  somewnat  nebulous 
terms;  in  the  current  context,  low  soeed  refers  typically  tc 
ICO-SoQG  3PS  and  high  speed  refers  to  data  rates  Greater  than  50 
KBPS.  The  rationale  for  tne  typical  situation  is  as  follows: 

1.  A high  speed  line  is  most  often  used  for  snort 

distances;  that  is,  beginning  and  ending  within  the 
same  controlled  area. 

2.  A typical  remote  SLACK  user  would  communicate  througn  a 
cnannel  conforming  to  MIL-STD-18S  or  FS-232. 

RED  users  are  not  precluded  from  BLACK  data;  a RE D user  »ould 
ootain  BLACK  data  on  a RED  line. 

modularity  is  considered  essential  if  the  SCCKF  is  to  fill  its 
multipurpose  role.  With  a bus-structured  minicomputer,  the  I/O 
capaoility  is  acnieved  via  a pluggaole  I/O  card.  TEriEESI  cesian 
proclams  are  minimized  if  tne  RED/ E LACK  modularity  is  implemented 
m clocks  of  one  I/O  card.  Also,  maximum  flexibility  can  be 
acnieved  oy  placing  tne  RED/BLACK  data  isolators  in  a seoarate 
isolator  nodule  (or  chassis).  Thus,  only  users  who  require 
PEC/BLACK  data  isolation  would  utilize  tne  module.  Strictly  RuD 
users  would  not  utilize  the  module. 

PED/BLACK  isolation  and  implementation  of  modularity  are  further 
aiscussed  in  tne  Technical  Coordination  Letter  (TCL)  ho.  2 
"BECJRL  C 0 i-u'i  L Ml C AT I C K S PROCESSOR  (SCCilP)  TEMPEST  RECLIRLME.i  IS" 
wnich  was  submitted  to  the  Air  Force  on  19  September  1975.  This 
tecnnical  note  contained  the  recommendations  tnat  only  normal 
KED/RLJ  isolation  be  provided  cetween  different  levels  of 
classified  users  because  it  is  assumed  a properly  cleared  user 
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vvould  not  act  in  a covert  manner.  With  the  modularity  scheme 
proposed  and  TEMPEST  isolators  at  the  output,  any  reasonable 
number  of  REE  users  could  oe  isolated  to  normal  RED/ 6 LACK  levels. 

The  system  design  effort  has  been  documented  in  the  TEMPEST 
CONTROL  FLAN,  (Confidential) , submitted  to  tne  Air  Force  on  29 
October  1975.  The  TEMPEST  CONTROL  PLAN  is  the  major  output  of 
the  TEMPEST  test  during  this  program  pnase.  It  outlines  tne 
TEMPEST  program  and  contains  the  applicable  documents  and 
requirements.  It  defines  the  TEMPEST  subsystem  requirements  for 
tne  chassis,  RED/BLACK  isolators,  power  supply  filters,  cabling, 
bonding,  grounding,  and  connectors. 

EMC  ' 


A responsible  TEMPEST  program  must  be  interrelated  to  the  EMC 
design.  The  EMC  requirements  are  MIL-STE-461A  and  MIL-STC-462. 
Tne  major  EMC  design  constraint  is  the  imposition  of  TEMPEST,  as 
tne  two  disciplines  are  interrelated  but  not  necessarily 
compatible.  For  example,  the  power  line  filter  was  selected  on 
tne  basis  of  meeting  TEMPEST  requirements,  ratner  than  EMC 
requirements . 

An  EMC  Control  Plan  was  generated  outlining  a program  to  acnieve 
EMC  compliance  in  a suitable  minicomputer.  The  EmC  Control  Plan 
was  suomitted  to  the  Air  Force  as  TCL  No.  4 on  23  October  1975. 
As  with  tne  TEMPEST  plan,  it  defines  system  and  subsystem 
requirements,  includina  the  chassis,  controls  and  indicators, 
caoling  and  connectors.  It  includes  a preliminary  Ground  and 
Return  diagram  which  is  somewnat  peculiar  to  tne  preliminary 
TEMPEST  mecr.anization  selected. 


3.7  60C0/Ser les  5L  Interface  Unit 

The  Interface  Unit  (IU)  required  for  interfacing  to  the 

6L)C0/Series  60  IU  is  a complicated  device  with  many 
implementation  alternatives  in  tne  area  of: 

1.  Entry  Fort  to  the  6000/Series  60 

2.  Number  of  entry  ports 

3.  Intercommunication  rate,  channel  width,  and  number  of 
channels 

4.  Data  formats 

5.  Separation  distances  accommodated. 

Tradeoff  data  was  developed  for  the  various  alternatives  and 
presented  at  Technical  Interchange  Meetings.  (Also  see 
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" 6Q0C/Ser ies  60  ID  Trade  Study",  TCL  No.  7 wnich  was  submitted  to 
tne  Air  Force  on  1 December  1975).  As  a result  of  the  tradeoff 
data  and  functionality  requirements,  the  following  aesign 
decisions  were  made: 

1.  Utilize  an  Input  Output  Multiplexor  (IOM)  port  in  lieu 
of  oirectly  entering  the  System  Control  Unit  (SCU)  of 
the  6000/Series  60. 

2.  Utilize  tne  Direct  Channel  interface  to  the  IOM  in  lieu 
of  the  Feripneral  Systems  Interface. 

3.  Design  to  accommodate,  though  do  not  implement  a 2C0C 
foot  separation  between  SFEP  and  6CC0/Series  60. 

4.  Implement  single  (hardware)  communications  channel  (with 
software  multiplexing). 

5.  Accomodate  greater  than  128K  words/sec  burst  transfer 
rate . 

leased  on  these  implementation  ana  functionality  decisions,  a DS 
Fart  I specification  was  developed  wnich  defines  the  current 
functionality  implementations . 


Task  Output 

Tne  Design  Specification  for  tne  IU  provides  a detailed 
functional  definition  of  the  current  IU  implementation . It  was 
submitted  to  tne  Air  Force  as  the  "6000  II  Functional 
Specification"  and  is  now  undergoing  review  and  revision. 


3.6  5 COMP  hardware  Verification  Metnodolocies 


The  major  objectives  of  this  "ask  were  to  investigate  computer 
•hardware  verification  methodologies  aoplicaole  to  a secure 
Communications  Processor  (SCCK?)  and  to  select  recommended 
techniques  which  accomol isn  each  verification  element.  Two  major 
verification  elements  were  identified  for  analysis.  They  arc: 

1.  Prooabilistic  measures  analysis  of  security  compromise 

induced  by  hardware  failure.  For  tnis  element,  the 

impact  of  unrel iaoil ity  in  tne  physical  hardware  on 
Secure  Communications  Processor  performance  must 
ultimately  be  analyzed  and  quantified. 

2.  Certification  t.nat  the  SCOMP  hardware  accomplishes  the 

performance  requirements  of  its  design  specifications. 
For  tnis  element,  tne  hardware  certification  criteria 
and  methodology  for  aesign  analysis,  desian  testing,  ana 
production  product  control  must  be  selected  and 

speci f ied . 
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approach 


A general  investigation  of  the  form  and  character  of  available 
analytic  tools  and  process  techniques  applicable  to  hardware 
verification  was  conaucted.  The  investigation  served  to 
establish  the  specific  tasks  appropriate  to  accomplishing  the 
protaoil istic  measurement  analysis  and  the  certification  of  the 
SCOwP  hardware  design  and  physical  product.  Additionally,  tne 
range  of  the  available  methodologies  for  each  task  which  should 
be  a candidate  for  detail  study  and/or  tradeoffs  was  also 
determined.  A Technical  Note  on  SCOMP  Hardware  Verification 
Methodologies  which  contains  descriptions  of  tne  work  elements 
necessary  to  achieve  probabilistic  measurement  and  hardware 
certif ication  and  an  overview  of  candidate  methodologies  was 
submitted  (TCL  No.  6,  11  November  1975,  "A  Technical  Note  on 
SCGMp  hardware  Verification  Methodologies"). 

The  methodology  tradeoffs  descrioed  above  were  performed  and 
suitable  criteria  were  selected,  '..here  further  tradeoffs  were 
inappropriate  to  a specific  task,  tne  task  criteria  have  beer, 
develooed  and  specified.  These  criteria  are  contained  in  tne 
appropriate  detailed  specifications,  Cuality  Assurance  Provisions 
sections,  for  tne  SP..  anc  IU. 


Conclusions 

The  hardware  verification  methodologies  investigation  has 
resulted  in  recommendations  in  three  areas: 

1.  Probabil istic  measure  analysis  techniques 

2.  hardware  design  certification  techniques 

3.  Physical  product  test  and  certification  criteria 

a manual  probabil istic  measures  analysis  technique  was 
recommended.  A SCOMP  functional  level  of  analysis  was  determined 
to  oe  more  suitaole  than  a detail  electronic  circuit  analysis  cf 
every  component. 

Ai  Kegister  Transfer  Level  (RTL)  simulation  is  recommended  to 
accomplish  the  hardware  design  certification.  The  simulation 
would  encompass  the  S PM  and  the  portions  of  the  CPU  dedicated  to 
support  tne  SPM  interface.  A similar  technique  may  also  do 
employee  for  the  6U(iC/Series  6G  IU. 

Test  and  inspection  criteria  were  developed  and  included  in  tne 
SP.-.  hardware  DS  Fart  I speci  f ications . Tnese  criteria  include 
reference  monitor  functional  specif ications . These  criteria 
include  reference  monitor  functional  exercising,  electronic  carts 
loqical  tests  fer  production  units,  and  configuration  inspections 
to  insure  integrity  of  the  production  product. 


•The  assign  verification  report  describes  in  detail  all  tradeoffs 
performed  ana  concomitant  recommendations . It  has  been  published 
as  " frooabilistic  Measures  of  Compromise",  ESC-T.F-76-16C. 


3 . 9 future  Plans 

Future  plans  are  to  complete  the  St EP  design;  fabricate,  test 
and  evaluate  prototype  SFLPs  and  support  integration  into  tne 
prototype  Secure  Mul tics  systems  on  a schedule  consistent  with 
program  requirements.  A detailed  description  of  future  plans, 
schedules  and  pnasings  are  delineated  in  the  Honeywell  document 
"Multics  Security  integration  Requirements"  (31  October  1575), 
Section.il.  This  document  is  now  in  review  and  preparation  for 
publication  as  an  ESD  Technical  Feport. 


4.0  SECURE  MULTI CS  DEVELOPMENT 


A secure  computer  system  is  one  wnicn  can  successfully  protect 
all  data  entrusted  to  it  from  unauthorized  disclosure.  This  is 
t.ne  basic  definition  of  system  security  or  more  specifically 
system  software  security  wnicn  guides  the  Cuardian  project. 
Issues  of  physical  security  which  can  deny  service  to  autnorized 
users  are  specifically  ignored  here  (e.g.,  fire,  flood,  etc.). 
The  major  concern  is  to  counter  all  security  t.nreats  which  would 
allow  someone  to  steal  information  (or  data)  from  the  computer 
system.  The  security  threats  of  general  interest  fall  into  tnree 
logical  areas:  malicious  persons  external  to  t.ne  system, 
authorized  users  of  the  system  and  collusion  between  authorized 
users. 

The  threats  from  malicious  persons  external  to  the  system  are  not 
particularly  interesting  to  the  system  software  designer.  These 
threats  include:  tapping'  communication  lines;  stealing  listings, 
tapes,  terminal  cutout  or  other  data  generated  oy  the  system; 
stealing  passwords  of  authorized  users;  monitoring 
electromagnetic  emanations  from  tne  hardware;  or  . ur.autnor  i zed 
actions  by  operations  or  administrative  personnel.  Each  of  tne 
tnreats  mentioned  can  only  be  countered  by  pnysical  or  crocedural 
security  measures  external  to  tne  computer  system.  The  only 
external  threats  of  interest  to  tne  system  software  designer  are 
illegal  attempts  to  enter  the  system  (loqin)  and  operational 
errors.  These  are  solved  by  the  use  of  passwords  for  user 
authentication  and  by  providing  unambiguous  instructions  and/or 
messages  to  operations  personnel. 

The  remaining  security  tnreats  come  from  users  authorized  to 
enter  into  and  use  the  system.  This  is  tne  area  of  particular 
interest  in  this  development  effort.  The  less  severe  internal 
tnreats  of  browsing  by  a curious  user  and  accidental  ar anting  of 
access  nave  jeer,  addressee  oy  tne  implementation  of  tne  access 
Isolation  Mecnanism.  The  insidious  threats  of  a Trojan  Horse 
program  or  system  penetration  remain  to  be  solved. 

v.itnin  tne  Multics  ar  cn  i tectur  e , a general  solution  to  the  threat 
of  a Trojan  Horse  has  not  been  found.  However,  for  a Trojan 
horse  program  to  be  able  to  compromise  data,  it  must  be  able  to 
communicate  between  security  levels.  Therefore,  one  requirement 
of  tnis  effort  is  to  eliminate  all  communication  patns  which 
would  allow  a program  to  reao  data  of  one  security  level  and 
write  it  where  it  could  be  read  from  a lower  security  level. 

A user  wno  can  penetrate  the  suoervisorv  elements  of  the 
operating  system  may  be  able  to  invalidate  ail  tne  access  control 
mecr.an  isms . A penetration  can  occur  from  incorrect 
implementation  of  tne  various  protection  mechanisms  or  fro.-,  a 
malicious  programmer  inserting  special  code  sequences  to  provica 
a "trap  door"  into  tne  operating  system.  Therefore,  another 
requirement  of  tnis  effort  is  to  verify  tne  correct 


36 


implementation  of  tne  Multics  operating  system  and  to  verify  that 
no  trap  doors  exist. 

ine  Multics  protection  mechanisms  are  implemented  within  the  most 
privilegea  protection  ring,  ring  0.  Unfortunately,  there  are  a 
large  number  01  programs  in  ring  0 whicn  are  very  complex.  Tne 
interactions  between  these  programs  are  also  complex  and  often 
subtle  or  obscure.  In  addition,  there  are  no  mechanisms  to 
protect  programs  and  data  within  ring  0 from  errors  in  other 
programs  in  tnis  ring.  'Inerefore,  any  attempt  to  verify  tne 
correctness  of  the  current  Multics  supervisor  as  it  exists  is 
doomed  to  failure  from  the  start. 

The  approacn  to  meeting  the  requirements  is  to  restructure  tne 
current  Multics  operating  system  to  isolate  tne  primitive 
mecnanisms  which  implement  the  security  access  controls.  This 
will  form  the  reference  monitor  or  security  Kernel  of  Multics. 
Tne  matnematical  model  of  computer  security  is  the  criterion  used 
in  defining  tne  interface  between  tne  kernel  and  other  carts  of 
tne  system.  Good  engineering  practice  requires  that  tne  current 
operating  system  be  molded  into  tne  new  structure  ratner  than 
attempting  a complete  top-down  redesign.  It  is  excectec  tnat 
several  iterations  between  top-down  specification  for  correctness 
proofs  and  bottom-up  design  for  engineering  feasibility  will  dp 
r.sedeo  . 


4 . 1 ha  jor  Accompl isnments 

Tne  activ ities . over  the  last  six  months  have  concentrated  on  the 
oottem-up  aefinition  of  tne  security  kernel,  external 
Input/Output  (I/C),  and  the  subsequent  restructur inn  of  tne 
remaining  Multics  supervisor  functions. 


Multics  Kernel 

me  Multics  s<ecurity  kernel  contains  all  functions  which  provide 
access  control  decisions  a.nd  all  hardware/software  mecnanisms 
necessary  to  support  the  access  control  functions.  It  is  these 
functions  which  must  eventually  be  certified  correct  for  Multics 
to  be  secure.  Tne  security  kernel  is  defined  to  include  all  Fine 
0 software  (simplified,  of  course),  all  trusted  orocesses,  the 
Central  Processing  Unit  (CPU)  hardware  itself-,  the  memory 
addressing  hardware,  tne  I CM  and  channel  hardware,  internal  I/O 
functions,  the  SFEF  communications  interface,  and  tne  external 
peripheral  I/O  interface.  A more  detailed  description  of  the 
Kernel  functions  is  being  oreoared  in  the  Multics  Kernel 
bpecif ication. 


secure  Input/Cutput  Services 

The  means  of  providing  secure  internal  I/O  functions  has  caused 
tne  greatest  concern  to  the  project.  The  original  MITRE  proccsal 
of  handling  all  external  I/O  through  the  StEP  has  been  replaced 
due  to  unwieldy  engineering  considerations.  Tne  nigh  bar.dwidtn 
interface  requirement  needed  to  support  high  speed  devices  and 
the  extra  problems  of  supporting  this  interface  over  a distance 
of  2000  feet' was  determined' to  be  less  practical  than  our  primary 
alternative.  »<e  have  cnosen  to  provide  nign  speed  perioheral  I/O 
services  through  the  IOMr which  will  have  to  be  sligntly  modified. 
This  method  of  supporting  I/O  is  presently  being  provided  within 
Multics.  Gome  nardware  modifications  to  the  IGH  have  been 
designed  which  will  snow  that  tne  ICM  and  the  current  software 
mechanism  (ioi  ) form  a complete  reference  monitor  for  these  I/O 
functions.  The_SFEP  is  still  required  for  nandling  the  external 
communications  I/O  functions.  It  has  been  determined  that  tne 
DATASET  6600  (tne  current  communications  processor)  and  the 
current  front-end  processor  software  (Multics  Communications 
System  - MCS)  cannot  be  certified.  Since,  by  its  nature,  a 
front-end  processor  must  handle  multilevel  data,  the  front-end 
processor  kernel  must  also  be  certified  just  like  the  Multics 
Kernel.  Tne  SEEP  approach  is  tne  only  way  found  to  support  and 
provide  tne  environment  for  certification.  The  results  of  tnis 
I/O  study  are  being  documented  in  a Technical  Coordination  Letter 
(TCL)  . 

Multics  Supervisor  Restructure 

Tne  simplified  security  kernel  and,  to  a lesser  extent,  the 
changes  to  handle  external  I/O  have  required  tne  restructure  of 
several  supervisor  functions.  The  possibility  of  removing  the 
directory  control  function  from  the  security  kernel  is  being 
investigated  and  appears  to  to  se  very  attractive,  as  opposed  to 
tne  approach  proposed  oy  MI TP 2.  Message  segments  have  been  moved 
into  the  security  kernel  since  they  contain  multilevel  data. 
Tne  impact  of  tnis  design  on  tne  user  interface  (e.g.,  mail  and 
interprocess  console  messages)  are  being  evaluated.  Some  new 
administrative  mechanisms  are  being  proposed  to  support  I/O 
device  assignment  according  to  the  security  model.  The  New 
Storage  System  (NSS)  design  has  enabled  some  new  system  features 
to  be  defined.  A most  desirable  feature  is  to  allow  creation  of 
upgraded  segments.  This  may  become  possible  when  some  proposed 
changes  to  the  quota  mechanism  are  fully  investigated.  The 
changes  to  tne  user  interface  and  restructuring  cf  supervisor 
functions  are  being  documented  in  the  Specification  for  a 
Prototype  Secure  Multics  System. 


5.0  SCOMP  SOFTWARE  development 


; 


Tne  objectives  of  this  phase  of  the  1975  program  were  to  specify 
a security  Kernel  for  tne  Secure  Communications  Processor  (SCGMF) 
and  to  begin  the  assign  of  this  security  kernel.  The  SCOMP 
security  kernel  should  be  general  purpose  in  nature%  and  a 
suitable  base  for  additional  software  to  permit  application  of 
tne  SCOMP  kernel  in  environments  other  than  just  as  tne  Multics 
Secure  Front-End  Processor  (SFEP)  being  developed  for  this 
program.  • 


Technical  Approacn 

Tne  SCOMP  security  kernel  approach  was  to  Dase  the  kernel 
requirements  on  those  requirements  outlined  in  the  initial  kernel 
specifications  provided  by  tne  Air  Force.  These  requirements 
were  then  reviewed  in  light  of  tne  Secure  Communications 
Processor  Specification  prepared  by  Honeywell  and  modified  to 
remain  in  accordance  with  tne  SCOMP  specifications.  Once  tne 
requirements  have  been  defined  for  a general  puroose  SCOMP 
Kernel,  then  these  requirements  will  be  translated  into  a Sr  CP 
kernel  Top  Level  Soeci  f ica tier. . 


»~«a j o r Accomplishments 

The  efforts  accomplished  during  this  time  frame  were  mainly  in 
training  software  personnel  to  understand  the  security  issues  as 
well  as  understand  tne  work  that  nas  been  performed  by  botn  the 
Air  Force  and  MITFS  in  tne  area  of  the  SCGMF  security  kernel. 
The  Air  Force  and  mITRE  have  been  developing  a security  kernel 
for  a general  purpose  communications  amplication  for  several 
years.  noneywell  nas  tried  to  use  this  effort  as  the  basis  for 
tne  SCO. if  kernel.  Tne  Air  force/MITPE  effort  nas  uncovered 
several  Key  security  issues  wnich  have  not  been  fully  adaressed 
in  their  effort.  Honeywell  nas  seen  trying  to  address  and 
resolve  these  issues.  MITRE  nas  also  been  working  on  a 
preliminary  definition  of  tne  SCOMP  kernel.  MITRE  nas  provided 
Honeywell  with  some  technical  guidance  on  tne  functional  aspects 
of  tne  kernel.  Honeywell  is  now  exoendina  its  efforts  on 
expanding  the  Kernel  functional  description  into  a too  level 
specification. 

Tne  Honeywell  approach  has  been  to  first  develop  a functional 
description  of  the  SCOMP  kernel.  This  was  required  so  that  the 
effects  of  tne  operating  system  and  communication  subsystem  could 
oe  incorporated  at  the  kernel  level.  This  functional  description 
was  then  reviewed  by  tne  Air  Force /MI THE  and  comments  were 
generated.  These  comments  are  now  oeing  factored  into  the 
functional  description  document. 
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In  addition,  Honeywell  personnel  are  in  constant  communication 
with  Multics  system  designers  to  establish  the  functional 
description  as  well  as  establish  the  Multics  kernel  to  SFEF 
kernel  interface. 

Cnee  the  functional  description  document  has  been  prepared,  then 
tne  effort  can  concentrate  on  the  development  of  the  Too  Level 
Specification.  Since  tne  learning  curve  was  longer  than 
anticipated,  tne  effort  on  developing  the  functional  description 
document  has  fallen  behind  schedule.  This  has  impacted  tne 
effort  required  to  prepare  a draft  of  the  SCO MP  kernel  top  level 
specification.  For  the  past  several  weeks,  Honeywell  has 
concentrated  its  personnel  on  preparing  the  specification  and 
will  continue  to  concentrate  its  personnel  on  this  task  until  an 
acceptable  SCCMP  kernel  top  level  specification  is  completed. 
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6.0  CERTIFICATION  ACTIVITIES 


During  this  reporting  period,  significant  progress  was  achieved 
in  tne  development  of  a methodology  to  certify  the  Multics  and 
SFEP  Kernels.  These  efforts  were  performed  oy  Stanford  Research 
Institute  (SRI)  as  a subcontractor  to  rioneywell.  Specif ical ly , 
SRI  prepared  three  significant  aocuments  related  to  tne 

certification  efforts  of  tnis  program  as  follows: 

1.  R.  J.  Feiertag,  Preliminary  Modularization  of  Multics 
(to  appear  as  a Technical  Coordination  Letter  on  £ 
January  1976) . 

2.  R.  J.  Feiertag,  PL/I  as  a System  Programming  Language 
tor  a Certifiable  Multics  (to  appear  as  a Technical 
Coordination  Letter  on  27  January  1976). 

3.  K.  N . Levitt  and  P.  G.  Neumann,  An  Interactive 

Environment  for  the  Specif ication.  Implementation,  and 
Certification  of  Multics  Security  Kernels. 


6 . 1 Tne  Proposed  Environ rent 

On  tne  basis  of  tne  work  to  date,  the  Interactive  Environment 
will  be  highly  supportive  of  tne  effort  to  certify  the  Multics 
security  kernel,  assuming  that  1)  tne  modularization  of  the 
revised  nultics  design  is  suitable  and  that  2)  suitable 
modifications  are  made  to  FL/I  to  make  it  appropriate  for 
certification  of  the  implementation  of  the  environment.  The  two 
Technical  Coordination  Letters  listed  above  both  give  significant 
promise  that  these  assumptions  can  be  realistically  assured. 
Also,  tne  development  of  tne  environment  is  realistic  on  tne 
desired  time  scale,  in  that  it  is  cased  on  existing  orototyce 
tools  and  on  a carefully  developed  speci f icaticn  language  (14), 
noth  of  which  are  currently  being  used  in  SRl's  secure  operating 
system  development  for  the  Department  of  Defense  wit.o 
ccnsiaerable  success. 

Tne  proposed  environment  includes  a data  base  for  keeping  tracx 
of  different  modules  of  tne  system  as  they  evolve,  including 
their  status  with  regard  to  specification,  implementation,  and 
proof.  It  also  includes  facilities  for  checking  syntactic  and 
(to  some  significant  extent)  semantic  consistency  of  the 
specifications.  These  tools  are  all  based  on  existing  working 
prototypes.  In  its  ultimate  form,  the  environment  can  also 
include  tools  for  formal  testina  and  semi-automatic  proofs  of 
correctness.  Rote,  however,  that  although  these  latter  tools  are 
only  partly  anticipated  by  existing  prototypes,  they  need  not  oe 
considered  essential  to  tne  verification  effort.  Nevertheless, 
even  tneir  partial  uevelopment  cojld  be  extremely  neloful. 
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Tne  environment  will  permit  effective  incremental  oroofs  of  the 
evolving  versions  of  Kul tics  once  the  first  certified  version  of 
Kultics  has  been  attained,  providing  an  indication  of  just  which 
steps  may  have  to  oe  reexamined  by  new  proofs.  It  also  will 
provide  significant  nelp  in  tne  development  process,  from  tne 
very  beginning.  Tne  use  of  the  methodology  (and  tne 
specification  lanquage  supporting  it)  should  considerably  enhance 
security  throughout  the  design,  implementation  and  proof  stages. 
Furthermore,  the  aoproach  is  immediately  extendable  to  the  proof 
of  security  (and  other  properties)  concerning  subsystems  and 
otner  parts  of  the  system  outside  of  the  kernel. 


6 . 2 Tne  Design 

Certification  of  security  will  be  feasible  only  if  tne  desian 
structure  is  appropriate.  A conclusion  of  the  Preliminary 
Modularization  of  Kultics  note  above  is  that  altnough  the 
existing  design  is  fairly  well  modularized,  it  is  not 

nier ar cnical . The  fact  that  much  functionality  in  the  present 
system  ooes  not  belong  in  the  Kultics  Ring  Zero  is  being 
addressed  oy  tne  .-.IT  researcn. 


6 . 3 The  Suitability  of  PL/I 

Tne  existing  PL/I  language  is  deficient  in  several  respects,  witn 
regard  to  cer tif iabil ity  of  tne  Kultics  security  kernel. 
Reference  2 (above)  proposes  specific  changes  to  the  language, 
some  involving  the  elimination  of  features,  others  involving  the 
restriction  of  existing  language  constructs. 


significant  recommendations  involve  strong  typing  of 
avoidance  of  "ur.soec",  of  mismatched  declarations, 
nonstandard  conversions,  restrictions  on  labels  and 
GCTG's,  protection  of  data  ana  proceaures  between 
Hierarchical  levels,  elimination  of  pictures  and  TL/I 
associated  built-in  functions. 


cc inters  , 
and  otner 
nonlocal 
different 
1/ G , and 
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APPEND I a A 


RUGGEDI2ED  LEVEL  6 


COMP UTL R DE VELOPEEN T PfcOGRAri 


(RAAL) 


I 


INTRODUCTION 


The  objective  of  tne  Honeywell  funded  RNML  development  program  is 
to  ruggedize  the  commercial  (HIS)  Level  6 minicomputers  for 
military  and  non-benign  commercial  environmental  applications. 
Tne  ruggeaized  computer  is  the  nardware  base  for  development  of 
tne  SCOi-it. 

In  order  to  contain  costs  within  specified  guidelines,  the 
computer  design  is  oriented  primarily  toward  grouna, 
grouna-mobile  and  transport  aircraft  applications.  Primary 
design  effort  is  directed  as  follows: 

1.  New  chassis  structure 

2.  Circuit  Card  stiffening 

3.  Pin  and  Socket  circuit  card  connector  changes  for  tne 
bus  interface 

4.  Power  supply  mounting 

5.  New  control  canel  structure 


II.  ELS IGN  APPROACH 


Cnassis  Design 


An  important  consideration  of  a militarized  or  ruoaedized  piece 
of  equipment  is  tne  aoility  of  tne  mechanical  structure  to 
witnstana  vioration  and  shock  levels  typical  of  a military 
environment.  Therefore,  tne  Level  6 computer  r uggedization 
program  involves  the  use  of  a precision  investment  casting  as  the 
nousing  for  tne  circuit  boards.  Tne  relatively  large  size  of  tne 
cnassis  container  coupled  with  intricate  external  rib  catterns 
ana  good  dimensional  accuracy  caoability  of  tne  precision 
investment  casting  process,  are  comoined  to  produce  a design  that 
is  botn  cost-effective  anc  sufficiently  rugged  to  meet  a variety 
of  military  service  environments. 

Figure  1 depicts  tne  RNHL  10  board  chassis  design. 


board  Stiffener  Concent 


figure  2 shows  the  board  stiffening  concept  for  military 
environment  applications.  Since  the  SFEP  application  does  not 
involve  exposure  to  vioration  or  severe  shock  environments,  the 
RNWL  board  stiffener  concept  is  modified  for  the  SFEP 
application;  i.e.,  only  a limited  number  of  stiffeners  will  De 
used  to  control  board  deflections  during  board  handling, 
installation  and  removal  operations.  For  the  SFEP  application, 
the  two  quarter-point  stiffener  members  as  shown  in  Figure  2 will 
be  deleted  to  simplify  production  and  reduce  costs. 


Circuit  Board  Connectors 


The  Level  6 computer  r ugged i zation  program  incorporates  an 
improved  plug-in  connector  for  electrical  interfacing  of  the 
motherboards.  Eecause  of  tne  large  number  of  electrical 
connections  associated  with  the  computer  backpanel , tne 
electrical  connector  used  in  this  application  represents  a 
critical  component  from  a reliability  standpoint.  Accordingly, 
the  basic  minicomputer  design  nas  been  modified  to  provide  a 
connector  mechanization  with  suoerior  dynamic  capability  and 
greater  long-term  reliability  than  the  existing  card-edge  system. 
The  proven  "blaae  and  fork"  connector  design  concept  shown  in 
Figure  1 has  been  used  successfully  on  several  Honeywell 
Aerospace  programs. 

The  connector  selected  for  the  RNML  application  will  provide 
improver:  reliability  for  both  static  (ground/laboratory)  and 
dynamic  (aircraf t/raobile)  environments  by  reducing  croolemS 
associated  with  corrosion,  oxidation,  humidity  and  dust  typically 
encountered  in  actual  service  conditions. 

A significant  feature  of  the  connector  mechanization  is  that  this 
approach  permits  use  of  tne  existing  multilayer  backpanel  design 
(witnout  change).  Positive  alignment  of  the  mating  connector 
pins  during  board  installation  is  accomplished  by  two  stainless 
steel  dowel  pins.  Additionally,  tnese  dowel  pins  and  their 
mating  nylon  bushings  will  provide  adequate  support  for  the  ooard 
and  stiffener  member  to  insure  that  the  connector  contacts  are 
not  stressed  under  mechanical  loads  during  ootential  shock 
conditions  associated  with  bench  hancli  ng/trar.spor  taticn 
environments . 

Power  Supply 

In  orcer  to  meet  the  overall  EMC  and  TEAFEST  requirements, 
special  attention  is  required  in  the  cower  supply  area.  The 
oasic  approach  to  meeting  these  requirements  is  to  mechanically 
isolate  the  power  supply  in  a separate  compartment  and  to 
electrically  decouple  the  unwanted  energy  from  tne  external  prime 
power  input  lines  and  from  each  internal  EC  power  source. 
Special  attention  will  be  given  to  grounding,  shielding,  and 
power  transmission  line  impedances. 

Tne  existing  power  supply  will  be  modified  to  incorporate  a 
structurally  different  method  of  mechanical  attachment  into  the 
main  ionL  chassis. 

Control  _Ear.el 

resign  modifications  have  been  made  to  ensure  that  the  control 
panel  satisfies  tne  vibr aticn/sr.ock  and  EMC/TEMFEST  protection 
requirements  as  cetailea  in  this  prooosal.  The  design  accroach 
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for  the  control  panel  involves  the  use  of  a separate  precision 
investment  casting  as  the  primary  structural  element  for  the 
panel.  Suitable  rF  I sealing  gaskets  and  screened-sh ielded  air 
inlet  openings  will  oe  incorporated  to  provide  specification 
performance  for  tne  EKC/TEKPEST  requirements. 

environmental  Design  Capability 

i'ne  details  and  specifications  of  Taole  1 establisn  the  intended 
cesign  capability  for  the  RRKL  equipment.  A more  detailed 
description  of  the  Rbti.nL  is  provided  in  Honeywell  Document  No. 
DS-BG8249A1  "Kuggedized  Level  6 computer  (RNKL)" , December  15, 
1975. 
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TAELE  1 


ENVIRONMENTAL  DESIGN 


ENVIRONMENT  SPECIFICATION  REMARKS 


Operating  Temperature 

MIL-E-4158 
MIL-E-1 6400 

Non  Operating  Temp. 

MIL-E-4158 

MIL-E-16400 

MIL-E-5400 

Vibration 

MIL-E-4158 

MIL-E-16400 

NIL-E-54C0 

MIL-E-5400 

Snoc  k 

MIL-E-4158 

MIL-E-5400 

MIL-E-16400 

Humidity 

MIL-E-4158 

MIL-E-16400 

MIL-E-54CC 

Altitude  (Operating) 

MIL-E-4158 

salt  Spray  lest 

MIL-E-16400 

_1 ectro-  an.netic 
Co.:  aatici  i ity 

MIL— STD- 461 

iL.'.f  . 

NACSLM  5100 

0 

deg . 

C 

to 

+ 52 

deg . 

C 

0 
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hi.  ri;kl  qualification  tests 


ine  RfJML  will  be  subjected  to  inspection  and  proof  tests  as 
defined  in  Honeywell's  Qualification  Test  Plan,  dated  January  31, 
1976,  to  verify  that  tne  PutoL  and  its  components  meet  tne 
intended  specification  requirements.  The  RNHL  Qualification  Unit 
will  oe  fabricated  and  inspected  to  Engineering  Released 
Drawings . 


A more  detailed  description  of  the  'Qual if ication  Tests  to  be 
performed  is  provided  in  Honeywell's  "Qualification  Test  Plan", 
QTP-EG8249A1 ,’  January  31,  1976. 


APPENDIX  E 


This  appendix  lists  the  major  documentation  that  were  produced 
during  tne  past  six  months.  Due  to  the  imminent  availability  of 
several  significant  reports  and  specifications  in  January  1976, 
additional  documentation  currently  in  preparation  is  also 
provided . 

many  other  internal  notes  and  working  documents  were  also 
developed  during  the  last  six  months  but  are  not  included  in  the 
following  lists. 


Technical  Coordination  Letters  (TCL) 

- ' * f 

Curing  tnis  reporting  period,  Honeywell  initiated  tne  Technical 
Coordination  Letter  (TCL)  series  of  documents.  These  technical 
notes  communicate  important  technical  issues  and  efforts  as  they 
appear  during  technical  review,  investigation,  and  worthing 
meetings.  The  TCLs  that  are  expected  to  be  available  in  January 
1976  are  also  listed. 


TCL  NO. 

Date 

Title 

TCL- 1 

19 

Sep 

1975 

Use  of  the  Honeywell  TCL 

TCL- 2 

19 

Se? 

1975 

SCOMF  TEMPEST  Requirements 

TCL- 3 

19 

Sep 

1975 

SFM  Specification  - Preliminary 

TCL- 4 

23 

Cc  t 

1975 

EMC  Control  Plan 

1CL-5 

27 

Get 

1975 

Meeting  Minutes  - SftP  Technical 
'working  Meeting  - 24  Sep  1975 

TCL- 6 

11 

Nov 

1975 

SCCHf  Hardware  Verification 
Me  thodolog ies 

TCL- 7 

1 

l 

Dec 

1975 

6000/Series  60  Interface  Unit 
Trade  Study 

To  L—  6 

12 

Dec 

1575 

Meeting  minutes  - SFtP  Technical 
Interchange  Meeting  - 5 Nov  1975 

TCL- 9 

19 

Dec 

1975 

Draft  of  S PH  Design 
Specification,  iart  I 

TC L- 1 0 

19 

Dec 

1975 

Craft  of  6000/ Series  6C  Interface 
Unit  Design  Specification,  Part  I 

TCL- 1 1 

6 

Jan 

1976 

Meeting  minutes  - Sr£F 
Software  Technical  Interchancre 
Meeting  - 9 December  1975 

TCL-12 

19 

Jan 

1976 

Meeting  Minutes  - SRI  Activities  - 
Technical  Interchange  Meeting, 

15  January  1976 

TCL- 13 

27 

Jan 

1976 

PL/I  as  a System  Programming 
Lanauage  for  a Certfiable  Multics 

TCL- 14 

27 

Jan 

1976 

Preliminary  Modularization 
of  Multics 

TCL- 1 5 

31 

Jan 

1976 

Initial  Description  of  Multics  I/O 

1 


Contract  Da ta  Items 

Luring  this  reporting  period,  numerous  technical  reccrts  and 
specifications  were  submitted  to  tne  Air  force  for  review  and 
approval.  The  following  is  a list  of  these  Data  Items  (CDPL's) 
and  tneir  respective  status.  Also  included  are  those  CDRL's  that 
will  be  submitted  to  the  Air  Force  in  January  1976. 


CCKL  No. 

Date 

Title 

AO  01 

15 

Oct 

1975 

Cuarterly  Report  for  the 

Period,  July  1975  - Seotemoer  1975 

15 

Jan 

1976 

Cuarterly  Report  for  the 
Feriod,  Sep  1975  - Dec  1975 

AO  0 2 

15 

Aug 

1975 

Monthly  Report  for  July  1975 

14 

Sep 

1975 

Montnly  Report  for  August  1975 

10 

Nov 

1975 

Monthly  Report  for  Cctooer  1975 

10 

Dec 

1975 

Monthly  Report  for  Nov  1975 

A004 

12 

Sep 

1975 

Interim  Report  (Draft) 

27 

Jan 

1976 

Interim  Report  (Revised  Draft) 

A005 

12 

Sep 

1975 

Final  Resort  (Draft) 

31 

Jan 

1976 

Final  Report  (Revised) 

« 0 u G 

31 

Get 

1975 

Muitics  Security  Integration 
Requirements  - 1 January  1576 
to  31  December  I960  (Draft) 

AC07 

31 

Oct 

1975 

Effects  of  a Muitics  Security 
Kernel  (Draft) 

AC08 

31 

Jan 

1976 

Muitics  Kernel  Specification  (Draft) 

AO  1 3 

31 

Jan 

1976 

Secure  Muitics  Specif icaticn  (Draft) 

A014 

30 

Sep 

1975 

Security  and  Integrity 
Procedures  (Draft) 

14 

Dec 

1975 

Security  and  Integrity 
Procedures  (Pevised  Draft) 
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